Zero to one · September 2026 · 8 min

What changes when you are the whole team?

A conversation about doing the product work, technical work and release work yourself, and what that really asks of you.

When you say you built Tilawa alone, what do you mean?

I mean I was the only person responsible for moving it from the idea to something people could install and test. I have to be careful with the word alone because I used tools other people built, and teachers and testers gave me information I could not have produced myself. I did not sit somewhere and invent every part of the technology.

What I mean is that inside the product there was no separate person for mobile, backend, design, payments, QA or release. If sign-in was confusing, I had to notice it and change it. If incoming calls stopped working when an iPhone was locked, that problem came back to me. If the payment provider changed the API, I had to update the server functions, the web flow, the verification, the tests and the support side. There was no point where I could say that another department would take it from there.

What was a normal day like when you were working across all of that?

It could change very quickly. I might start with a database issue around two students trying to call the same teacher, then move to wording on the minutes page, then spend time in App Store Connect trying to understand why a build was not appearing. Later I might be looking at a Sentry error for a font or testing why a livestream worked on Android and failed on iOS.

The hard part was not always the complexity of one task. It was keeping the connection between them. If I changed what the website promised, I had to check whether the backend behaved that way. If I made the payment flow easier, I still had to think about store rules and what would happen when the user left halfway through. You can solve each ticket correctly and still end up with a product whose parts disagree.

Did being the same person across the product ever make things easier?

Definitely. I did not need a meeting to explain why a backend change affected the customer message because I was already holding both sides. When the payment integration changed, I could see it as one movement across the endpoint, webhook, reconciliation, page, admin records and tests instead of waiting for several teams to discover the dependencies one by one.

That speed is real, especially early on when the product is still changing shape. The problem is that all the context can stay inside your head without you noticing. Something feels obvious because you remember the conversation that led to it, but six months later even you may not remember, and another engineer certainly will not. I had to start turning those decisions into tests, notes and repeatable release steps.

How did you choose what to work on when everything needed you?

I kept coming back to what the user would lose if I got it wrong. A visual issue can make the app look unfinished, and that matters, but money, identity, privacy and the state of a live call can cause actual harm. I would fix the thing that could charge someone twice before the thing that made the splash logo feel too large.

I also looked at how difficult a decision would be to reverse. I can rewrite a paragraph quite easily. A weak database decision becomes harder once real accounts, payments and session records depend on it. This did not make the list shorter, but it stopped me treating every item as if it had the same weight.

People often say solo builders move faster. Did you?

In some ways, yes. There were no hand-offs and I did not have to wait for somebody else’s sprint. If I understood a change properly, I could take it through several layers in the same day. That is one reason the product became as complete as it did with one person.

There is another side to it, though. I did not have another engineer sitting beside me to question the assumption I had made at the beginning. Sometimes I spent hours testing a theory that was simply wrong. I also switched context so often that I could be busy all day and still feel that I had not stayed with any one problem long enough. Working alone removes coordination time, but it does not remove the need for challenge or the limits of one person’s attention.

What did you put in place so the product did not depend on your memory?

The manual test checklist grew a lot. Every time something surprised me, I added a way to check it again before release. The automated tests held rules around sessions, roles, payments and database access. I built admin views because I did not want every support question to turn into me opening the database and reconstructing what happened manually.

I also became more serious about why a rule existed, not only what the code did. If somebody joins the work later, they need to know why failed sessions do not consume minutes or why some boundaries are enforced in the database instead of only in the app. Otherwise a future improvement can quietly remove a decision that was protecting somebody.

Would you tell other people to build this way?

I would tell them there is value in understanding the whole problem, but I would not pretend that doing everything alone is the final form of a company or a product. It gave me a range I am genuinely proud of. I now understand how product decisions travel into architecture, operations, support and release because I had to follow them myself.

At the same time, good people make the work better. They question what you have normalised, bring depth where you have been stretched and carry parts of the system with more attention than one person can give forever. I do not want the achievement to be that Tilawa always needs me for everything. I want the achievement to be that I carried it far enough and made it clear enough for a strong team to join it.

What changed in how you see yourself after doing it?

I stopped seeing my work as receiving a specification and turning it into code. I am comfortable now with the stage before there is a specification, when the problem is still unclear and somebody has to decide what should exist. I can move from that uncertainty into a product decision, build the system, release it and stay with it when real people find the parts I missed.

I do not think that means I will know every answer at the start. Most of the time I did not. The confidence came from learning that I can keep asking the next useful question without losing sight of the whole product.