Building as a founder-engineer — what I protect first

Most engineering advice assumes someone else owns the roadmap. Founding changes that. At T2devs I am still writing code, reviewing PRs, and shipping releases — but I am also the person who decides which problem is worth the next month of life.

That combination is powerful and dangerous. Powerful because there is no translation loss between product intent and implementation. Dangerous because it is easy to confuse busyness with progress, or to polish a system nobody asked for.

This is how I try to stay honest when I am both founder and engineer.

Start from the problem people feel

Prospective thinking does not mean inventing features for a future that never arrives. It means asking: six months from now, what will still hurt if we ignore it?

When I started T2 Shop, the tempting work was UI chrome. The durable work was tenant isolation, split fulfillment, and an API that a POS and a storefront could share without lying to each other. Those were not glamorous tickets. They were the difference between a demo and a business.

A useful filter I use in client work and studio work alike:

What breaks under real load? Not marketing load — operator load. Admins, cashiers, support, content editors.
What is expensive to reverse? Schema choices, multi-tenant boundaries, payment ledgers.
What creates trust? Clear status, honest errors, releases that do not surprise people on Monday morning.

If a task fails all three, it can wait.

Own the boring path to production

Founders love architecture diagrams. Customers love software that is up.

As a founder-engineer I schedule the unglamorous path early:

Environments that actually differ (dev / stage / prod)
A release habit you can explain in one paragraph
Observability on the flows that make money or reputation

Prospective engineering is not predicting every edge case. It is leaving a path the next version of you — or a teammate — can follow without archaeology.

When I lead delivery for other teams, I look for the same smell: a beautiful frontend with no story for rollback, or a product demo that has never survived a real deploy. Fix that before you hire for more velocity.

Decide what not to build

The hardest founder skill is saying no with a reason.

I keep a short written list of non-goals for active products. Not a manifesto — a page. Examples from recent work: “We are not building a marketplace in v1.” “We are not customizing the admin per tenant until three tenants ask for the same thing.”

That list protects engineering from polite chaos. It also protects sales from over-promising. Prospective thinking includes the cost of options you leave open forever.

Stay close to the craft without becoming the bottleneck

I still want to write the hard parts myself — the API contracts, the first embeddable widget, the payment edge cases. I do not want to be the merge gate for every label color.

The balance that works for me:

I own the risky seams — auth, tenancy, money, delivery.
I write defaults — how we structure modules, how we name environments, how we review.
I review for outcomes — does this change make the product more truthful under stress?

Leadership as a founder is creating conditions where shipping does not require me in the room. Leadership as an engineer is still caring about the seam that will fail at 2 a.m.

Think in systems, ship in slices

Prospective engineers sketch the system; good founders ship a slice that proves the system.

For commerce and admin products I like a rhythm:

One vertical slice that a real user can complete end to end.
Instrumentation on that slice.
Harden the shared core (auth, tenancy, audit).
Expand horizontally only after the slice survives contact with reality.

This is slower than a big-bang build on a whiteboard. It is faster than rewriting a fake product three times.

Takeaway

Founder-engineer work is product judgment wearing a keyboard. Protect the problems that stay painful if ignored, ship the boring path to production, write down what you will not build, and keep your hands on the risky seams without becoming the team’s critical path. The goal is not to predict the future — it is to leave a business and a codebase that can meet it.