How I choose what to build next at T2devs

Running T2devs means living inside a permanent queue of good ideas. Client work, product ideas, open-source curiosity, “we should rebuild that.” The constraint is not imagination. It is attention.

As a founder who still engineers, I needed a way to choose the next build without pretending every opportunity is equal. This is the framework I actually use — not a theory deck.

Three lenses, in order

I score a candidate project — studio product or client engagement — through three lenses. Order matters.

1. Pain that already exists

I look for pain people already pay for with time, money, or workarounds. Spreadsheets beside the “real” system. Manual reconciliation after every order. Content teams waiting on engineering for every landing page.

If the pain is only theoretical (“someone might want AI here”), it waits.

Questions I ask on discovery calls and in my own product notes:

What do you do today when this breaks?
Who gets woken up?
What have you already tried?

Prospective founders invent markets. Practical founders listen for existing tax.

2. Risk I can reverse

Even painful problems can be bad bets if the first version requires irreversible commitments I am not ready for: regulated money movement without partners, marketplaces that need two-sided liquidity on day one, hardware dependencies.

I ask: what is the smallest version that teaches us something and can be thrown away without shame?

T2 Shop started as an API-first commerce engine with a clear tenant model — not a global marketplace. That was a reversible bet with expensive seams protected early (tenancy, payments, inventory). Prospective engineering showed up as what we refused to fake.

3. Leverage for the studio

Not every paid project strengthens the studio. Some only rent hours.

I prefer work that leaves behind:

A sharper point of view (commerce, content systems, delivery discipline)
Reusable judgment (how we run releases, how we structure APIs)
Relationships that compound

Pure commodity ticket-work can fund the month and starve the year. Founder judgment is knowing which is which.

The one-page bet

Before I commit serious time, I write one page:

Problem — in the customer’s words
Non-goals — explicit
First slice — what “done” means in two to four weeks
Risks — technical and commercial
Kill criteria — what would make us stop

If I cannot write the page, I do not understand the bet yet. Sales pressure is not a substitute for clarity.

This habit also protects engineering. Vague ambition becomes thrash. A written slice becomes a backlog you can respect.

Saying no without burning the bridge

Most “no” is timing, not rejection. I say:

“Not now — here is what would make it a yes.”
“This needs a partner we do not have yet.”
“This is a staff augmentation ask; we are a product studio.”

Prospective reputation is built on clean no’s. Engineers remember founders who over-promised them into a corner. Clients remember studios that took work they could not stand behind.

Revisit the queue on a rhythm

I review open bets on a fixed cadence — not every time someone emails. Weekly for active delivery, monthly for bigger studio bets.

Each item either:

Stays with a reason
Moves up because pain got louder
Dies because the world changed

A queue without kills becomes guilt. Prospective founders prune.

Takeaway

Choose the next build by existing pain, reversible risk, and studio leverage. Write a one-page bet, say no cleanly, and prune the queue on a rhythm. Founder-engineer judgment is less about having more ideas — it is about protecting attention for the few that deserve a shipping path.