Starting Before You Feel Ready

Nobody feels ready.

I didn't feel ready when I started working as a software engineer, and I didn't feel ready when I started a company. The feeling doesn't go away when you're prepared enough. It goes away, a little, once you've started.

What this means

"Ready" usually means "certain it'll go well." You won't get that before you start. You get it, partly, by starting.

So the question isn't am I ready? It's what's the smallest real step I can take now, with what I already have?

What I learned

My own path into tech was not a tidy one.

I started my software engineering career in 2023. For a while, my days were college in the mornings, development work through the day, and learning late into the night. I also shared what I was learning on LinkedIn and on this blog. I kept building, and opportunities followed: some people hired me, some trusted me as a lead, some invited me in as a co-founder.

In January 2024, about a year into that career, I founded a small software company, Yaks Inc. I ran its day-to-day operations, managed teams working on products and mobile apps, and did software consulting.

I was not "ready" to run a company a year into my career. Nobody told me it was time. I learned a lot of it on the job, which is how most of it gets learned.

The lesson I took from that period: starting is a skill, and like other skills it gets easier with practice. The first thing you start is the hardest.

Real example

Two examples of starting with what already exists instead of building everything.

Chhithi AI. I built an AI PDF summarizer: upload a PDF, get summarized insights. I didn't train a model. I used OpenAI's API for the summarizing and built the product around it with Next.js, Tailwind, and Stripe. The interesting work was the product, not the AI model itself.

HairOver's website. I didn't build a custom content system. It's a static Astro site with content collections, a sitemap plugin, and Vercel analytics, all standard tools. Here's how it's built. My time went into the parts that mattered: the guides, the page structure, and tracking the path from reader to install.

In both cases the approach was the same: use existing tools for everything that isn't the core. Build the part that's actually yours.

Overthinking and perfectionism

Overthinking looks like research. You read one more article, compare one more tool, redesign the logo once more.

Perfectionism looks like quality. "I'll launch when it's good enough."

I've definitely done the second one. The clearest example is HairOver's landing page, which I rebuilt about four times before it had real traffic. Each version was a little better. None of them was tested by a real visitor. (The full story.)

A test I use now: will doing more of this tell me something new? If another round of polish won't teach me anything, it's probably perfectionism dressed up as work.

Building with limited resources

Limited resources aren't only a disadvantage. They force good decisions:

• You can't build ten features, so you build the one that matters.
• You can't buy a big ad budget, so you learn how to get attention for free.
• You can't hire a team, so you find out which work actually needs doing.

The trap is using "no resources" as a reason to wait. Most first versions need very little: some time, a laptop, and a few cheap or free tools.

AI-assisted building

AI tools have made it a lot cheaper to start. You can draft, prototype, and analyze much faster than before.

My caution, from building AI products: AI makes the doing faster, not the deciding. It can help you write a pricing model, but you still have to check the assumptions. My own first HairOver pricing model was missing the app store commission, and a tool won't catch what you never thought to ask about. (The pricing story.)

Use AI for speed. Keep the judgment calls for yourself.

When to outsource, and when to do it yourself

My rough rule:

• Do it yourself if it decides whether the business works: understanding customers, core product decisions, pricing, early sales.
• Use existing tools for solved problems: hosting, payments, analytics, email, components.
• Outsource well-defined work that isn't your strength and would otherwise hold up everything else for weeks.

As an engineer, my risk is the opposite of most people's. I can build almost anything myself, so I'm tempted to. That doesn't mean I should.

What to do

1. Write down the smallest real step you could take this week. Make it small enough to finish.
2. List what you'd build from scratch, then cross out everything an existing tool already does.
3. Set a date for putting something in front of real people, and tell someone about it.
4. Use AI for drafts and speed, and check every assumption yourself.
5. Ask the "new information" question before each round of polish.

Mistakes to avoid

Waiting to feel ready. That feeling tends to come after you start, not before.

Building what you could buy. Your time is the scarcest resource you have.

Confusing research with progress. Reading about starting isn't starting.

Letting a tool make a decision. AI can help you think. It can't own the call.

My current thinking

I still feel unready most of the time, just about bigger things now. With HairOver, it's distribution and monetization, not code. I've accepted that the feeling is normal, and I try to treat it as a signal to take a small step, not to wait.

Key takeaway

You won't feel ready, and you don't need to. Take the smallest real step, use existing tools for everything that isn't your core, let AI speed you up without deciding for you, and stop polishing when it stops teaching you anything.

Next: Building a Business Model.