Working Alone
The solo engineer startup is one of the most common configurations in early-stage companies. You are the frontend engineer, the backend engineer, the DevOps person, the database admin, the customer support rep, and often the one doing sales calls too. This is not a dysfunction — it is a legitimate and sometimes optimal way to build a product. But it requires a specific set of habits to avoid the traps that solo builders fall into.
The biggest dangers are not technical. They are over-engineering without anyone to push back, context-switching until nothing gets finished, and building in silence until you realize nobody wants what you built.
The Solo Builder's Reality
A typical day for a solo technical founder:
09:00 Fix a production bug reported by a user on Twitter
09:30 Reply to 3 customer support emails
10:00 Work on the feature you planned to ship today
11:00 Get interrupted by a payment webhook failure
11:30 Debug the webhook issue
12:00 Realize you need to update your DNS settings
12:30 Lunch while reading about DNS
13:00 Back to the feature
14:00 Sales call with a potential customer
15:00 Back to the feature
16:00 Deploy what you have, discover a CSS bug on mobile
16:30 Fix the CSS bug
17:00 Write tomorrow's to-do list
17:30 Realize you shipped half the feature you planned
This is normal. The key is not eliminating interruptions — it is building systems that let you make progress despite them.
How to Prioritize
When everything is your job, everything feels urgent. It is not. Use a simple framework:
Priority tiers for solo builders:
P0 - Production is down or users cannot pay you
→ Drop everything. Fix it now.
P1 - A customer reported a bug or asked for help
→ Respond within hours. Fix within the day if possible.
P2 - The feature you committed to shipping this week
→ This is your "real work." Protect time for it.
P3 - Everything else (refactoring, nice-to-haves, optimization)
→ Only if P0-P2 are clear. Usually weekends or slow periods.
The trap is spending all day on P1 and P3 while never touching P2. Customer support and code cleanup feel productive because they are immediate and completeable. Feature work feels hard because it requires sustained focus. Protect two to four hours of uninterrupted time for P2 work every day. Block your calendar. Close Slack. Turn off email.
Pieter Levels, the solo founder behind Nomad List and RemoteOK, is famous for shipping multiple profitable products alone. His approach: ruthless prioritization, managed services for everything, and a rule of shipping something visible every single day. He does not refactor code that is working. He does not optimize performance until users complain. He ships.
Use Managed Services Instead of Building
The single most important decision for a solo builder: never build what you can buy or use for free.
Build vs Buy for solo engineers:
Authentication → Use Clerk, Auth0, or Supabase Auth. Never roll your own.
Payments → Stripe. Period.
Database → Managed Postgres (Supabase, Neon, Railway). Not self-hosted.
Email sending → Resend, Postmark, or SendGrid. Not your own SMTP.
File storage → S3 or Cloudflare R2. Not your own file server.
Search → Algolia or Meilisearch Cloud. Not Elasticsearch on a VPS.
Monitoring → Sentry for errors, Betterstack or UptimeRobot for uptime.
Hosting → Vercel, Railway, Fly.io, or Render. Not bare EC2.
CI/CD → GitHub Actions. Not Jenkins on a server you manage.
Every service you self-host is a service you maintain. When it breaks at 2am, you are the on-call engineer. When it needs security patches, you are the ops team. When it runs out of disk space, you are the one getting paged.
The math is simple: a managed Postgres instance costs 15/month is burning money, not saving it.
The Danger of Over-Engineering
Without code review, there is nobody to say "this is too complex" or "you don't need this yet." Solo engineers are uniquely vulnerable to over-engineering because:
Over-engineering traps for solo builders:
- Building an abstraction layer for a feature that exists in one place
- Setting up microservices when a monolith would serve 10,000 users
- Writing a custom ORM because existing ones "don't fit"
- Spending a week on a plugin system when you have 3 users
- Building a custom admin dashboard instead of using a spreadsheet
- Implementing GraphQL subscriptions for an app with 50 daily actives
The antidote is a question: "Would a senior engineer reviewing this PR tell me to simplify?" If the answer is yes, simplify. Imagine the most pragmatic engineer you know looking over your shoulder. What would they cut?
Sahil Lavingia built Gumroad largely as a solo operation for years. His approach was aggressive simplicity: a Rails monolith, no microservices, minimal abstraction. When people asked about his architecture, his answer was basically "it's boring and it works." That is the goal.
The YAGNI Principle in Practice
You Aren't Gonna Need It:
Planning to support multiple databases? → You have one database. Build for one.
Building a multi-tenant architecture? → You have one customer type. Build for one.
Designing a plugin system? → You have zero plugins. Build the features directly.
Creating a configuration management system? → Use environment variables.
Building API versioning? → You have zero API consumers. Ship v1.
Every abstraction layer is a maintenance burden. Every unused feature is dead code. Every "just in case" system is complexity that slows you down every time you touch the codebase.
Ship Daily to Stay Accountable
When you work alone, it is easy to spend three days "researching" or "refactoring" with nothing to show for it. The discipline of shipping something every day forces you to break work into small pieces and maintain forward momentum.
What "ship daily" means:
- Push code to production every day (even small changes)
- If the feature is not done, ship what is done behind a feature flag
- Write a short log of what you shipped (public or private)
- If you cannot ship code, ship a customer conversation or a decision
What "ship daily" does NOT mean:
- Rushing to push broken code
- Skipping basic testing
- Avoiding larger tasks that take multiple days
- Burning out by forcing artificial deadlines
The build-in-public movement on X (formerly Twitter) exists largely because solo builders discovered that public accountability prevents stagnation. Telling people what you shipped today creates a feedback loop: you ship because people are watching, and people watch because you ship.
The Daily Standup With Yourself
End of day check-in (5 minutes, written):
1. What did I ship today?
2. What blocked me?
3. What is the ONE thing I will ship tomorrow?
Keep these in a simple text file or Notion page. Review weekly.
After 4 weeks, you will see patterns: where you get stuck, what
type of work you avoid, which days are productive vs wasted.
Managing Context Switching
The solo builder's worst enemy is context switching. You cannot eliminate it, but you can reduce its cost.
Context switching strategies:
- Batch similar work: customer support in one block, coding in another
- Set "office hours" for support: check email/support 2x per day, not constantly
- Use timeboxes: "I will work on this feature for 2 hours, then switch"
- Keep a "parking lot" list: when something interrupts you, write it down
instead of acting on it immediately (unless it's P0)
- Use your calendar as a commitment device: block focus time and honor it
Cal Newport calls this "time blocking" and it is not optional for solo builders. Without it, your day is driven by whatever notification arrives next.
When to Stop Being Solo
Working alone is a valid configuration, but it has limits:
Signs you need help:
- You are regularly working 60+ hour weeks and still falling behind
- Customer support volume prevents you from building
- You are avoiding critical technical work because it's outside your expertise
- Growth is limited by your personal throughput, not by demand
- You have not taken a day off in months because nothing works without you
The transition from solo to a two-person team is one of the most impactful changes a startup can make. It more than doubles your output because it removes the bottleneck of a single person's attention.
Common Pitfalls
- Building in silence. Shipping features without talking to users is the most expensive mistake a solo builder can make. Talk to users before you build, while you build, and after you build. Your code is a hypothesis. Users are the experiment.
- Perfectionism without a reviewer. Without someone to say "good enough, ship it," solo builders can polish indefinitely. Set a timebox for every task. When the timer goes off, ship what you have.
- Ignoring operations. "I'll set up monitoring later" means you find out about outages from angry users. Basic monitoring takes 30 minutes to set up and saves you hours of debugging.
- Not taking breaks. The solo builder identity can consume you. The startup does not die if you take a weekend off. It does die if you burn out.
- Comparing yourself to funded teams. A solo builder cannot ship as many features as a team of ten. That is obvious but easy to forget. Compete on speed and focus, not on volume.
Key Takeaways
- Use managed services for everything that is not your core product. Your time is the scarcest resource. Do not spend it running databases or managing infrastructure.
- Ship something every day. Daily shipping forces small batches, maintains momentum, and prevents multi-day rabbit holes.
- Protect two to four hours of uninterrupted focus time for feature work. Batch support, email, and operational tasks into separate blocks.
- Fight over-engineering aggressively. Imagine a pragmatic senior engineer reviewing your code. If they would say "simplify," simplify.
- Recognize when solo is no longer working. The signals are clear: sustained overwork, growing support burden, technical blind spots, and growth limited by your personal bandwidth.