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 hard part is not making the first version large. It is making the first version specific enough to teach you something.
From early build to software an elevator maintenance company could try on live jobs.
Job intake, technician assignment, quotations, status updates, customer records, and invoicing.
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 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 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 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. |
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.
