Last year I tried my first startup. We moved fast, and the mistakes came just as fast. I learned a lot in the end, and if I did the same thing today I would run it completely differently. In this piece I'll walk through that process and the lessons I took from it.
The startup was called Kaptanos (Captain, as in kaptan, plus Operating System). We were trying to automate routine material purchasing for mid-sized construction companies. Today that purchasing runs through Excel, WhatsApp, email and the phone. A purchaser spends a real part of the day on it, calling suppliers, collecting prices in a chat, trying to keep track of who offered what and on which terms. Because the process is scattered, time gets lost and errors and delays pile up. On top of that, when a firm starts a project in a city it doesn't know, it has to buy from unfamiliar suppliers in that area, and in those cases the odds of being scammed are high. That was what we wanted to solve. Enter the need in one place, let the system find suppliers, compare the offers, and place the order in minutes.
The reason the startup ended was that my technical co-founder and I couldn't agree on how to build the product. But we had set the order of the work wrong from the very start, meaning what to do when, what to validate first and what to build after. That order mistake is what I really want to write about.
What we were trying to build
The first target was mid-sized construction firms and their routine indirect-material purchasing.
It's worth defining "indirect material," because the whole idea rests on it. Indirect material is the consumable and operational supplies a project uses but that don't go into the structure itself and are hard to assign directly to one project. Gloves, drill bits, stationery, small site supplies are examples. They get bought over and over, in small amounts.
The plan had two phases, and the phases split along the type of spending.
Phase one was OPEX. OPEX (operating expenses) are the repeated, low-value purchases a company makes in its day-to-day operations. That's where the pain repeated most. The flow I designed went like this. The user enters a need (what, how much, where), the system suggests suppliers based on location and past data, it sends automatic quote requests and compares prices and delivery times, the user approves, the order goes to the supplier, and a simple record is kept of who sold what and at what price.
Phase two was CAPEX. CAPEX (capital expenditure) is long-term asset investment, like buying an excavator. Here the work changes. The purchaser wants to go, see and inspect, and the process takes a long time. You don't place a one-click order for an excavator. So that phase added an analyst-assisted review for high-value items, compliance and certificate checks, faster reporting, and optional integration with the heavy systems large firms already run everything through (ERP systems like SAP or Oracle).
We started by betting on small and mid-sized firms, thinking large firms already had procurement systems. But large holdings showed interest too, because we had first focused on the items that get purchased continuously.
What we did, and in what order
First we talked to experts. Construction project managers, sector leaders who had done procurement for years. They were easy to reach and generous with their time.
From those conversations I wrote a hypothesis. Then I did the market sizing. Then I prepared the pitch deck.
We applied to a Singapore-based VC's accelerator program and passed the first of two selection stages. Their feedback was a very basic thing, and looking back it was the most useful thing anyone told us. Talk to more potential customers.
Reaching the people who would actually use the software was hard. Most weren't on LinkedIn. So we went office to office, dropping in unannounced. People gave us their time anyway. Nobody resists having their problem heard.
One thing I noticed there. In SMEs there was no clear "purchasing" title. There was an ownership ambiguity, and everyone did a bit of everything.
By the time I got here I had produced a lot. I had written detailed personas. A purchaser at a 50-to-150-person firm, a project manager running 5 to 15 active sites at once. User stories and workflows for each. A two-phase MVP scope. Even a detailed workflow diagram. With my technical co-founder I was discussing how all of this would be implemented on the technical side, and we were going to the offices together.
We had also scoped a narrow proof of concept (a PoC, the smallest possible first test of the idea). It deliberately stayed away from the hard part, the continuous and contract-heavy purchases like concrete and rebar. Instead it focused on a single one-off purchase. The example we used was a contractor who needed drainage pipes for a site outside its home city. Enter the location and the material, let the system list suppliers that fit the distance and transport constraints, collect three offers, compare price and delivery date, place and record the order, and measure how long the whole thing took.
On paper it looked complete. But we had put all of it together before confirming which problem actually mattered to the people who would use it.
What the users actually said
The real information was in the office visits, and it didn't line up with the tidy plan.
One purchaser opened up like this. "I'd want to learn Excel, but I don't have the time." That changed what the product had to be. Being better than Excel wasn't enough. It had to need almost no learning.
The recurring pains were clear, one by one.
- The offer process was scattered across Excel, phone and WhatsApp, and prices, supplier details and terms kept getting lost.
- Finding local suppliers was hard, especially on sites outside the company's home city, where their own network didn't reach.
- Regulation and logistics made it worse. For items like concrete and rebar there were distance limits, transport bans and delivery-hour restrictions, and picking the wrong supplier cost time and money.
- There was fraud and kickback risk, from unclear approval limits and close supplier relationships that inflated prices.
- The purchase types weren't the same problem. One-off buys and continuous buys behave differently, and the big continuous ones drag in slow, complex contracts.
After some of these visits, a few firms asked to join the test period.
That felt like a win, but it wasn't the kind we needed. Wanting to try something is interest, not validation. Validation is someone actually using the product, coming back to it, and finding it worth their time or their money. We hadn't seen that from anyone yet, because we hadn't built the one thing that would have tested it.
Where we went wrong
The mistakes look like separate things, but they're the same one repeated.
We sized the market without knowing which problem hurt enough, and for whom. The experts explained the industry well, but they weren't the users, and we reached the users late. And by the time a different disagreement became impossible to ignore, we still hadn't settled on the single most painful problem.
The order was backwards. We did the work that feels like progress, the deck, the market sizing, the personas, the roadmap, before the work that would have told us whether any of it was right.
Why it ended
My co-founder wanted to build the software first, without testing it with users along the way, and spend the rest of the year selling it. I wanted to stay close to users, find the most painful problem first, and build in steps.
The problem was that we never agreed on which one Kaptanos was. It turned out that a disagreement about one feature was really a disagreement about the whole method. We caught this problem early, and we decided to end the project before it grew any bigger. Kaptanos ended there.
There's another side to this too. More validation isn't the answer on its own. If validation never turns into building, talking to users quietly becomes a way of putting building off. As YC keeps telling founders, the point is to launch fast. Validate the one thing you need before you build, then ship quickly.
What I'd do differently today
I'd check that one specific problem actually hurts before sizing the market. If people don't feel a sharp enough pain to change how they work, the size of the market doesn't matter.
I'd go to the real users first, even when the experts are easier to reach. An expert can describe the industry. Only a user can tell you what they'd drop Excel for.
I'd launch fast around the most painful problem, the way YC keeps telling founders. Then I'd watch who uses it, who comes back, who finds it useful and who pays. We never got that far.
I'd take the co-founder choice slowly. a16z's advice is not to rush it, and I understand why now. Before committing, agree on how you'll build. How much you validate, how fast you move, how close you stay to customers, and when you start writing code. If you can't agree on that in calm times, you won't agree under pressure.
Everything doesn't have to be this fast
There's one more lesson I took. Not everything has to be incredibly fast, and that pace wears you down.
For two weeks, every time I fell asleep I had the same dream. The same nightmare, really. It was always the same thing. I was making the MVP plan, deciding what the first version of the product would be. Even sleep had turned into more of the work.
Later I came across the approach of Basecamp's founders, and my thinking on this changed. I saw that I don't have to run at maximum speed all the time, that good work can come out of a sustainable pace too.
What it taught me
In the end I had personas, a two-phase roadmap, user stories, a pilot scenario, a workflow diagram and a pitch deck. We joined one accelerator program in Turkey, and our participation in a Singapore-based program was cut short.
But we never had a single validated problem. I spent most of my time on the work around finding that problem, not on the problem itself.
All of this completely changed how I think about running an early-stage startup, and it taught me a lot.