What being the only engineer at a startup taught me

I've been freelancing since 2020, including work with international clients. I started building AfterBoards in 2023, first as a freelancer and then full-time. AfterGrad came later. Between them, I look after two web apps, two mobile apps, the backend, and the tools the content team uses.

Being the only engineer means I can move quickly. It also means a decision I make today is usually mine to maintain six months from now. There isn't another team to hand it to.

Keeping four apps manageable

I use TypeScript across the stack and keep the apps in one Turborepo. Shared types and product rules save me from implementing the same change separately for web and mobile, or for AfterBoards and AfterGrad.

That matters most when I'm switching between jobs. I might work on an exam flow, investigate a payment, and help the content team on the same day. Having related code together makes it easier to pick each task back up.

I try to judge a tool by the whole job it lets me finish. Next.js and Server Actions work for me because I can build a screen and its backend together. Adding another service has to save enough work to justify running it too.

Decisions without a regular review loop

Writing the code is often easier than deciding how much to build. When I'm unsure, I ask what the product needs now and what I'll have to maintain afterwards.

I became more cautious about abstractions as the codebase grew. If I can't explain which repeated work one removes or which failure it prevents, I leave it out. I can add it when I have a clearer reason.

Mobile makes recovery slower

On the web I can deploy a fix and have users pick it up quickly. A mobile release takes longer, and some people keep using an older version.

That pushed me to spend more time on interrupted connections, old clients, sign-in issues, and payments whose status hasn't caught up yet. A feature isn't finished just because it worked on my phone with a good connection.

What I pay attention to now

I used to think more about how many features I could finish. Now I spend more time asking what happens when something fails, how I'll find out, and whether a user can recover.

I still like working across the whole product. Seeing the content team use an internal tool or a student finish an exam gives me a better sense of what to work on next. It also makes the maintenance cost hard to ignore: I'm the person who will be fixing it.

The AfterBoards and AfterGrad case study covers the apps, exam engine, payments, and content tooling in more detail.