From Idea to MVP in 3 Months as the Only Developer

In early 2021, I quit my job to build a CRM for maintenance companies in Europe. Three months later, I had a working product, paying customers, and the conviction to raise a $2.7M seed round.

This isn't a story about working 16-hour days or some superhuman productivity hack. It's about making ruthless decisions about what matters and what doesn't when you're building alone.

Most founders overcomplicate MVPs. They build for six months, twelve months, sometimes longer. They hire engineers before they have customers. They optimize for scale before they have traction.

I took the opposite approach. Here's exactly how it worked.

Why Being the Only Developer Can Be an Advantage

At Mainteny, I had a cofounder handling the business side while I owned the entire technical stack. This setup is common in early-stage startups: one person on sales, partnerships, and operations; one person building the product.

Some would call this risky. What if the developer gets hit by a bus? What about code review? Who validates technical decisions?

All valid concerns. And yet, for an MVP, being the only developer has one massive advantage: speed of execution. No debates about architecture. No pull request reviews. No waiting for someone to finish their task before you can start yours.

You decide, you build, you ship. The feedback loop is instantaneous.

For an MVP—where the goal is learning, not scaling—this matters more than anything else. Every hour spent in technical discussion is an hour not spent shipping. Every compromise to accommodate another developer's preference is a potential delay.

"Speed is the ultimate weapon in business. All else being equal, the fastest company wins."

I'm not saying one-person dev teams are better long-term. They're not. But for the MVP phase specifically, having a single person who can hold the entire codebase in their head and make instant decisions is a superpower.

The time to build a proper engineering team is after you've proven the concept works. After you know what you're building and why. In those early uncertain months, having one technical brain making all the calls eliminates coordination overhead entirely.

Scoping Ruthlessly: The Art of Strategic Omission

Here's the hardest skill in building an MVP: deciding what not to build.

Mainteny was a CRM for maintenance companies—HVAC technicians, plumbers, electricians. These businesses have complex needs: scheduling, dispatching, inventory management, invoicing, customer communication, reporting.

A "complete" solution would take years to build. I had three months.

So I asked one question obsessively: What is the one thing that, if it works, proves the business is viable?

For Mainteny, the answer was scheduling and job management. If maintenance companies would pay for a better way to manage their daily jobs—assigning technicians, tracking progress, capturing job details—everything else could come later.

Everything else got cut. No inventory management. No invoicing integration. No mobile app (initially). No fancy reporting. No user permissions beyond basic admin/technician roles.

The "won't have" list is the most important document you'll create. It's not a backlog—it's a commitment to yourself that you won't get distracted.

My won't-have list for Mainteny had over 40 items. Every time a potential customer mentioned a feature, I added it to the list instead of the roadmap. This let me acknowledge their need without committing to build it.

Counterintuitively, customers respected this. They'd rather have a focused tool that does one thing well than a bloated mess that does everything poorly.

Time Management: The Solo Developer's Calendar

When you're the only person building, every hour is a trade-off. An hour helping with a customer demo is an hour not spent coding. An hour fixing a bug is an hour not spent on new features.

I tried every productivity system imaginable. What actually worked was dead simple: fixed blocks for fixed activities.

The morning coding block was sacred. I treated it like a meeting with the most important person in the company—because it was. If a customer wanted to talk at 9am, I'd offer 2pm instead. No exceptions.

This structure meant I got roughly 24 hours of focused coding per week. Over three months, that's about 300 hours. Enough to build an MVP if you're not wasting time on the wrong things.

The afternoon block was for everything else. I batched all calls into this window. Customers learned that I was available 1-5pm and planned accordingly. This constraint actually made me more responsive, not less—they knew exactly when they could reach me.

What to Build First (And What to Skip)

The sequencing of what you build matters as much as what you build. Get it wrong and you'll spend weeks on infrastructure before you have anything to show customers.

Here's the order I followed:

Week 1-2: The Core Loop

The first thing I built was the core user journey: create a job, assign it to a technician, mark it complete. No login system (I hardcoded a test user). No database migrations (I reset the database constantly). No error handling beyond basic try-catch.

By the end of week 2, I could demo the core flow to customers. It was ugly and broken in dozens of ways, but it showed the idea clearly enough to get feedback.

Week 3-4: Just Enough Authentication

Only after validating the core loop did I add user accounts. I used Spring Security with the simplest possible configuration—username/password, no OAuth, no social login, no password reset (I'd manually reset passwords via database).

This is where most developers over-engineer. They spend weeks building a perfect auth system before the product even exists. Don't. Build the minimum that lets multiple users access the system. Everything else can wait.

Week 5-8: The Feature Set

With the foundation in place, I built out the must-have features: customer management, technician management, job scheduling with a calendar view, basic status workflows, and simple reporting.

Each feature followed the same pattern: build the simplest version that solves the problem, ship it, get feedback, iterate only if necessary.

Week 9-10: Polish and Infrastructure

Only in the final weeks did I invest in infrastructure: proper deployment pipeline, monitoring, backups, and the things needed to run in production reliably.

This ordering is important. If I'd started with infrastructure, I'd have a beautiful deployment pipeline and no product. By leaving it until the end, I ensured I was only building infrastructure for something that actually worked.

What I Deliberately Skipped

• Unit tests: Yes, this is heresy. But for an MVP where code will be rewritten anyway, extensive testing is premature optimization.
• Documentation: I was the only developer. I'd document when there was someone else to read it.
• Performance optimization: With a handful of users, performance doesn't matter. Optimize later.
• Mobile responsiveness: The desktop version came first. Mobile could wait.
• Internationalization: We launched in one market with one language.

Each of these is important eventually. None of them matter for proving the initial hypothesis.

Tech Stack Decisions: Boring is Beautiful

When you're building alone, the temptation to try new technologies is strong. Don't. This is not the time to learn Rust or experiment with a new database.

I chose the most boring stack I knew well: Spring Boot for the backend, PostgreSQL for the database, and vanilla JavaScript with some jQuery for the frontend (yes, really).

Why Spring Boot? Because I'd used it for years and could write it in my sleep. I knew exactly how long features would take. I knew where the pitfalls were. I could debug issues in minutes instead of hours.

Some founders questioned the Kubernetes choice—isn't it overkill for an MVP? Maybe. But I'd deployed dozens of applications to Kubernetes before. I could set up a cluster and deploy an app faster than I could configure a traditional VM setup.

That's the key insight: choose technologies based on your speed with them, not their theoretical fit. A technology you know deeply beats a technology that's "better" but unfamiliar.

The frontend is where I compromised the most. A React or Vue app would have been more modern, but server-rendered templates with JavaScript sprinkled in let me move faster. When you're the only developer, having one codebase instead of two is a massive simplification.

Getting Customers While Building

The biggest mistake technical founders make is building in isolation. They spend months coding before talking to customers, then discover they've built the wrong thing.

I started selling in week 3, before the product could really be used.

Here's how: I reached out to maintenance companies with a simple pitch—"I'm building a tool specifically for businesses like yours. Can I show you what I'm working on and get your feedback?"

Nobody says no to this. You're not selling; you're asking for help. People love giving advice.

These conversations did three things:

• Validated the problem: Were these businesses actually struggling with the pain I was solving?
• Shaped the product: What features did they actually need versus what I assumed they needed?
• Created a pipeline: Some of these early conversations converted to paying customers.

By the time the MVP was ready, I had a list of 15 companies waiting to try it. Three became paying customers in the first month.

The trick was being honest about the product's state. I told prospects exactly what worked and what didn't. I promised to fix things quickly when they broke. I gave them my personal phone number for support.

Early customers don't expect perfection. They expect to be heard. If you can demonstrate that their feedback directly shapes the product, they'll tolerate rough edges.

The Fundraising Inflection Point

With three paying customers and a working MVP, I had what I needed to raise: proof that the market existed, proof I could build, and proof that customers would pay.

The seed round came together quickly after that. Investors could see a product, talk to real customers, and evaluate actual usage data. This is infinitely more compelling than a pitch deck alone.

The $2.7M gave us runway to build the team, expand the product, and grow the customer base. But none of it would have happened without those three months of focused solo building.

What I'd Do Differently

Looking back, some things worked well. Others I'd change.

Keep: Aggressive Scoping

Cutting features ruthlessly was the right call. Every feature I didn't build was time I could spend on the core product or talking to customers.

Keep: Fixed Schedule

The morning coding blocks were essential. Without protected time for deep work, I'd have been constantly context-switching.

Change: Start Customer Conversations Earlier

I waited until week 3 to start talking to customers. In retrospect, I should have started in week 1, before writing any code. The conversations would have shaped even the initial architecture.

Change: Build Analytics From Day One

I added usage tracking late and regretted it. Understanding how customers actually used the product would have helped prioritize features better.

Change: More Aggressive on Pricing

I underpriced initially because I lacked confidence. Customers who would have paid more were happy to pay less. This left money on the table and made the unit economics look worse than they should have.

Change: Better Error Handling

Skipping comprehensive error handling saved time initially but cost more later. Some balance between "perfect error handling" and "no error handling" would have been smarter.

The Solo Developer Advantage

Building an MVP as the only developer isn't about being a hero or proving you don't need a team. It's about moving fast during the phase where speed matters most.

Once you've validated the concept, build the engineering team. Once you have product-market fit, scale the organization. But in those early uncertain months, when you're searching for what works, having one person who can pivot the architecture instantly, ship daily, and iterate without coordination overhead is a genuine advantage.

Three months. One developer. One product. Three customers. That's all it took to prove the idea was worth pursuing.

The rest is execution.

Have questions about building your MVP or navigating the early startup journey? Feel free to reach out—I'm always happy to chat with founders who are in the trenches.

Prasad Subrahmanya

Founder & CEO at Luminik. Previously built Aura at Bain ($3.6M ARR) and led Mainteny ($2.7M seed). Building AI-powered tools for B2B teams.