Prospective engineering — designing for the problem after this one

“Think ahead” is easy advice and bad practice when it becomes speculative frameworks for imaginary users. Prospective engineering, the way I mean it, is quieter: build today’s product so tomorrow’s change does not require a rewrite — without paying for tomorrow up front.

As founder of T2devs and as a senior engineer on client platforms, I live in that tension every week. Agencies want speed. Startups want optionality. Both punish systems that only work for the happy path of the current sprint.

Here is the mental model I use.

Separate reversible decisions from expensive ones

Not every choice needs a committee. Paint colors and button spacing are cheap to reverse. Tenant boundaries, payment ledgers, identity models, and public API shapes are not.

Prospective thinking starts by labeling decisions:

Cheap to reverse	Expensive to reverse
UI composition	Multi-tenant data isolation
Internal folder layout	Auth and session model
One-off admin scripts	Money movement and refunds
Feature flags for experiments	Public API contracts

Spend design energy on the right column. Move fast on the left. Most “architecture debates” that burn a week are left-column work wearing right-column language.

Prefer contracts over frameworks

When I pick a stack — Go, Node, Next.js, whatever fits — I am less interested in the logo and more interested in the contract:

What is the API the UI can trust?
What is the event or job the worker can trust?
What is the environment variable matrix that stage and prod will not silently share?

Contracts age better than clever code. A clear OpenAPI document, a stable GraphQL schema with migration habits, or a boring REST resource model will outlive the framework fashion that surrounds them.

Prospective engineering is writing the contract as if a stranger will integrate against it in nine months — because they will. Sometimes that stranger is you.

Build delivery into the product

I have seen beautiful admin panels that could not be released safely. That is not prospective. That is unfinished.

The minimum delivery story I want on any serious build:

One artifact, many environments — promote what you tested.
Smoke checks after deploy — login, one critical read, one critical write.
A rollback you can name — previous artifact, flag off, or both.
Logs and metrics on the money path — not vanity dashboards.

Founders sometimes skip this because “we are small.” Small teams feel outages harder, not less. Prospective founders treat release habits as product features.

Leave seams, not speculative modules

Overbuilding often looks like empty folders: notifications/, billing/v2/, ai/, waiting for a future that never funds them.

Better pattern: ship the slice you need, but leave a seam — a clear interface where the next capability can plug in without rewriting the core.

Examples from work I have shipped:

Commerce inventory that can later split fulfillment because stock was never assumed to live in one warehouse table forever.
Embeddable widgets isolated from the host page so branding and runtime could evolve independently.
Content systems where authoring and publishing were separate concerns early, even when v1 only had one author role.

A seam is a decision. An empty module is a hope.

Review for future regret

In code review — including my own — I ask three prospective questions:

What will confuse the next engineer? Naming, hidden globals, magic env defaults.
What will break when volume is 10×? Lists without pagination, sync jobs without backoff, admin tables that load everything.
What will we wish we had measured? Latency on checkout, failure rate on webhooks, time-to-publish for content.

If a PR is fine for today but fails two of three, I still ship when the product needs it — but I file the follow-up while the context is warm. Prospective work includes making future pain visible, not pretending you already solved it.

Founder lens: optionality with a price tag

Every open option costs attention. As a founder I write down optionality I am paying for on purpose: “We keep the API public because partners are part of the bet.” And optionality I refuse: “We are not maintaining two storefront themes until revenue says otherwise.”

Engineers who only optimize for technical elegance under-price attention. Founders who only optimize for demos under-price reversibility. Prospective software engineering holds both.

Takeaway

Think ahead by protecting expensive decisions, writing contracts strangers can trust, shipping delivery as part of the product, leaving seams instead of ghost modules, and reviewing for future regret. The point is not to build the future early. The point is to meet it without starting over.