---
title: "How to build the first version of a startup product"
description: "A practical lesson from Mainteny: pick one market, make one daily workflow work, sell while building, and keep the stack easy to change."
canonical: https://prasad.tech/blog/mvp-three-months.html
source: html
generated_at: 2026-05-26T13:56:27.812Z
---
[Home](/) / [Blog](/blog/) / Zero to one 

 Aug 2025  9 min read Zero to one 

# How to build the first version of a startup product

A practical lesson from Mainteny: pick one market, make one daily workflow work, sell while building, and keep the stack easy to change.

The first version of a startup product has one job: make one important workflow better for one specific kind of customer. That gives you a useful test. You can see whether the customer uses it, where it breaks, and which parts of the company story still need evidence.

Mainteny taught me this in a useful way. We were building field service management software for elevator maintenance companies. The first useful version was built in three months because we made it live inside one daily workflow: office teams needed to schedule jobs, send technicians, issue quotations, invoice customers, and keep job history intact.

I wrote the first product myself and joined the commercial work. I sat in customer calls, watched objections turn into product decisions, and learned which parts of the workflow buyers cared about enough to change.

The argument in one paragraph 

A first product gets useful when the scope is concrete: one market, one workflow, one practical architecture. Mainteny’s first product made the company easier to understand. Here was the workflow, here was the software, here were the limits, and here was what customers were teaching us.

The first-version decision map

01**Choose one customer type**Elevator maintenance companies with office teams, technicians, and job history that had to stay intact.

02**Map one daily path**Request, schedule, dispatch, quotation, technician update, invoice, and customer record.

03**Build the narrow version**Enough product for a customer to run live jobs, with the deferred list visible instead of hidden.

04**Sell through the workflow**Use buyer questions to test the product model, the demo, the pricing, and the next scope decision.

05**Only expand what repeats**When the same pain appears in customer calls and daily use, it earns a place in the product.

The hard part is not making the first version large. It is making the first version specific enough to teach you something.

**3 months** First customer version 

From early build to software an elevator maintenance company could try on live jobs.

**1 workflow** Request to invoice 

Job intake, technician assignment, quotations, status updates, customer records, and invoicing.

**$2.7M** Round that followed 

The round was supported by a live product, customer conversations, and clearer evidence from the field.

## The customer was concrete

The first customers were maintenance businesses with technicians in the field, office staff handling calls, and building customers waiting for updates. One early customer exposed the product problem better than any generic market map could.

A job could start as a phone call, turn into a quotation, become a technician visit, require a follow-up part, and end with an invoice or a customer-dashboard update. If the software lost any step, the office still needed paper, spreadsheets, WhatsApp, or memory to close the gap.

> A first product earns trust when it removes one daily irritation without asking the customer to pretend the rest of the company is already automated.

## The first scope was deliberately narrow

The tempting version of the product was huge: scheduling, dispatch, quotations, invoicing, customer dashboards, inventory, customer communication, permissions, reporting, mobile apps, and integrations. The useful first version was smaller. It handled the work from request to invoice and left the rest visible.

|                      | Built first                                                                               | Deferred                                                      |
| -------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| Job operations       | Create work orders, assign technicians, update status, see customer history               | Advanced inventory and warehouse flows                        |
| Scheduling           | Calendar views and technician availability good enough for daily planning                 | Complex route optimization                                    |
| Commercial documents | Generate quotations and invoice PDFs with logo, line items, and customer-ready formatting | Full accounting-suite integration                             |
| Customer visibility  | Basic dashboard context for customers and assets                                          | Deep self-serve customer portal workflows                     |
| Mobile               | A React Native app for technician updates and field context                               | Every offline edge case and every device-specific polish item |

The first customer version had to make one workflow reliable before the product earned the right to expand.

## The technical choices were boring on purpose

I used tools I could move fast with and debug alone. The product needed to be reliable enough that customer calls produced product learning instead of apologies.

The first stack

- **Backend.** Kotlin and Quarkus for the API.
- **Frontend.** React for the web app used by office teams.
- **Mobile.** React Native for technicians in the field.
- **Database.** PostgreSQL, including custom indexing for the first search experience.
- **Search.** Custom Postgres-backed search first, Elasticsearch later when the product needed it.
- **Infrastructure.** AWS, with managed services where they saved time and custom code where the workflow needed it.
- **Third-party tools.** Used selectively for jobs like invoice PDF generation when building everything from scratch would slow customer learning.

The stack worked because every layer had a job. Quarkus and Kotlin gave me a typed backend with fast iteration. React kept the office workflow easy to change. React Native let technicians update work without waiting for a separate product cycle. Postgres carried the first product further than many people expect.

## Sales calls changed the product

The customer conversations were part of product work. A maintenance owner would describe a dispatch problem. A technician would explain why a status field was wrong. An office manager would ask what happened when a customer changed the appointment after the technician had already been assigned.

Those questions tested whether I understood the work. When I could answer with the actual behavior of the product, or say clearly what it did not handle yet, the conversation became more honest.

The sales lesson 

Technical founders have an advantage when they sell through the workflow. You can hear a customer objection and know whether it is a missing button, a weak data model, a bad promise, or a market signal the product should leave alone.

## The weekly rhythm protected customer learning

I treated the week as four blocks: build, customer calls, review, buffer. Mornings were for building. Customer calls and follow-ups had dedicated time. Planning happened after the customer work had created new evidence.

|          | Block                                             | Purpose                                                     |
| -------- | ------------------------------------------------- | ----------------------------------------------------------- |
| Build    | Deep implementation work                          | Move the product forward without meeting fragments.         |
| Customer | Sales calls, onboarding, support, and follow-ups  | Keep the product attached to real use.                      |
| Review   | Look at what customers actually did and asked for | Decide what enters the next build cycle.                    |
| Buffer   | Fixes and loose ends                              | Stop small reliability issues from becoming customer doubt. |

The schedule mattered because it kept building, selling, and support in the same week.

## What I would keep

- **One narrow market.** Elevator maintenance companies had enough shared workflow shape that learning transferred from one conversation to the next.
- **One complete daily path.** Request to invoice was more useful than five half-built modules.
- **Direct customer contact.** The technical decisions were better because I heard the commercial objections myself.
- **A practical stack.** I chose tools that made debugging and change cheap.
- **Honest demos.** Customers trusted clear limits more than polished answers that collapsed in real use.

## What I would change

- **Start customer calls even earlier.** Some architecture choices would have been sharper if I had heard the field workflow before writing the first version of the data model.
- **Instrument usage from day one.** Support calls tell one part of the story. Usage data shows where the product quietly fails.
- **Test pricing sooner.** Price tells you what kind of pain the buyer thinks you solve.
- **Write the deferred list more formally.** A visible list of postponed features helps customers understand focus without feeling ignored.

## The lesson I still use

A first customer version is part product and part market test. It teaches the market, makes sales conversations more concrete, and gives investors something real to evaluate.

The useful skill is knowing which part of the business must become software first. At Mainteny, the answer came from customer calls, elevator field-service workflows, and a stack I could change quickly when the truth changed.

![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) 

## Prasad Subrahmanya

Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team.

[LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) 

[ Back to blog](/blog/) 

## Filed under

Zero to one first productstartup productcustomer deliveryMainteny 

## Related notes

[**Building a $3.6M ARR product inside Bain**Aura reached $3.6M ARR inside Bain in 18 months. The useful lesson is which constraints helped, which slowed us down, and why.](/blog/zero-to-one-bain.html)[**Alfred: how I run repeated work as a solo founder**How I use Alfred to turn repeated company work into plans, summaries, draft replies, and pull requests I can review before anything ships.](/blog/alfred-solo-founder-operating-system.html)[**Separating agent work from founder work**Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me.](/blog/dedicated-mac-mini-solo-startup.html)