What I was tempted by

There was a newer framework everyone around me was excited about, plus a hosted database with a nice free tier and an edge setup that looked great in demos. None of it was bad. I just hadn't shipped anything real with any of it.

What I actually picked

A framework I had used for years, a plain Postgres database, a single server, and server rendered pages with a little JavaScript where it mattered. Nothing in that list would impress anyone reading a stack page.

Why boring won

The client cared about the thing working and being easy to change later. They did not care what it was built with. Every hour I spent learning a new tool's quirks was an hour I wasn't spending on their actual problem.

I also knew where the sharp edges were. When something broke, I usually recognised the error. With a new stack I'd have been searching forums for every odd behaviour, on a client's deadline.

And handover mattered. At some point someone else might maintain it. A common, well documented stack is much easier to hand to the next developer than something niche I happened to like.

What it cost me

It wasn't free. Some things were slower to build than they would have been with newer tools, especially parts of the UI. A couple of times I wrote code by hand that a newer library would have given me for free.

I also didn't learn much new on that project. That's a real cost if you enjoy the craft side.

How I decide now

For client work I use what I already know for the core, the database, the framework, hosting. If I want to try something new, it goes on a small side piece where a mistake is cheap, not in the middle of the build.

Do you pick your stack per client, or stick to one you know and accept the tradeoffs?

Write the job around the next six months

My first job description listed every technology we might ever touch. It attracted people who looked great on paper but did not fit what we actually needed. The second time, I wrote down the three problems the hire would own in their first six months. That made interviews far more focused and the candidates self selected much better.

Use a small paid task instead of puzzles

Algorithm puzzles told me very little about how someone would work inside our messy early codebase. A short, paid task that mirrored real work told me a lot more: how they asked questions, how they handled unclear requirements, and whether they wrote code someone else could read. Paying for the time also felt fairer and got more serious responses.

Be honest about the chaos

Early stage work is unstructured. Some candidates love that, some hate it. I stopped hiding it and started describing a normal week plainly, including the parts that are not glamorous. The people who stayed interested after that conversation were the ones who stayed long term.

Plan the first two weeks before they join

The first hire I made spent the first week waiting for access and context. Now I prepare a short onboarding doc, a small first task that can ship within days, and a clear person to ask questions. Shipping something early builds confidence on both sides.

Do not skip the paperwork

In India, getting the offer letter, contract terms, and IP assignment right from the start matters. Sorting it later is awkward and can become a real issue when you raise money.

None of this is complicated, but each step removed a source of friction that I had underestimated.

How did you approach your first engineering hire, and what would you change if you did it again?

Feedback becomes useful when it changes a decision. At the end of each test, record three things: what we expected, what happened, and what we will do next. Share the note with the people who contributed feedback. Even a short follow-up builds trust because people can see that their time mattered.

## Keep a steady rhythm

A practical weekly rhythm might be one customer conversation on Monday, a small change on Tuesday, an observation later in the week, and a Friday decision note. Some weeks will produce a clear improvement; others will simply rule out an attractive idea. Both outcomes reduce uncertainty.

Small loops make product work feel lighter because they replace vague pressure with visible progress. Teams do not need perfect research or a complete roadmap to learn. They need a clear question, a respectful conversation, and the discipline to act on what they discover.