A product team of one: writing code with a PM hat on

In my freelance years the job was clear: deliver what the client asked for, on time. When I started building my own products, the rules changed. Now I'm the one deciding "what to build", and that is much harder than writing the code.

The most expensive line is not the unwritten one; it's the unnecessary one

When you're solo, every feature costs you three times: while writing it, while testing it, and forever while maintaining it. So I filter every idea through a single question: can the app ship without this? If the answer is "yes", it doesn't make the first release.

When I launched Benim Sınavım, the list included a friend leaderboard, drawing tools and a mistake notebook. None of the three were in the first version; there was only question solving and score calculation. Once users arrived, the reviews showed me which one was actually wanted, and I built the roadmap from that.

The PM hat's greatest gift to the developer hat is the ability to say "no". Even to yourself.

The daily rhythm

The schedule that works best for me:

• Morning: product work. Reading reviews, stats and store data; deciding what to do.
• Afternoon: deep work. Only code, notifications off.
• Evening: release chores. Release notes, store copy, small fixes.

When I squeeze decision-making and coding into the same hour, both get worse; when I separate them, both get faster.

No feature without a measurement

In a team of one it's easy to over-trust your gut, because nobody pushes back. So after every release I look at three numbers: downloads, day-one retention and recurring requests in reviews. If a feature idea isn't backed by one of those three, it goes on the waiting list.

Building products alone can feel lonely, but it has one advantage: the distance between an idea and a release is less than a day. Keeping that speed comes from not building everything.