Architecture proposals: what founders should check first

Why big designs fool founders

Big design docs often look convincing before they prove anything. A neat system diagram, a long list of components, and confident language can make weak thinking feel safe. Detail gets mistaken for clarity.

The trap gets worse when a proposal solves more than the company asked for. A team starts with "fix slow checkout" and ends up with a plan to replace payments, rebuild user accounts, add event streaming, and change deployment pipelines. It sounds ambitious, but the extra scope can hide a basic question: why does the business need all of this now?

Polish also hides missing tradeoffs. Some senior engineers explain exactly how a new system will work, but skip what the business gives up to get there. If a redesign takes four months, delays a release, and raises cloud spend every month after launch, that matters as much as the diagram.

This is where founders get into trouble. A proposal can be technically correct and still be the wrong move. If the change does not protect revenue, speed up shipping, cut support pain, or remove a real risk, it may just be expensive motion.

You do not need to out-argue an engineer on technical details. Your job is simpler and harder: test the proposal, not the person who wrote it.

A fast review can start with four blunt questions:

• What breaks if we do nothing for the next 90 days?
• What work does this design remove?
• Which release does this delay?
• What smaller version could we ship first?

Those questions change the conversation. Instead of debating taste or seniority, you make the proposal show business impact.

Good technical leaders do this too. A seasoned Fractional CTO will usually look past the clean diagram and ask what can be deleted, postponed, or kept boring. The best design is rarely the biggest one. It is the one that fixes the problem without dragging the company into a larger project than it needs.

Start with the real problem

Most architecture proposals sound persuasive because they describe a cleaner system, better scale, or a nicer future. That does not mean the work matters this quarter. Before you approve anything, pin down the problem that hurts today.

Start with pain you can describe in one sentence. Maybe customers wait too long for reports. Maybe deployments fail often enough that the team loses hours every week. If nobody can explain the current problem in plain words, the proposal is probably early.

Then write the result you need. Keep it concrete. "Cut page load time from 5 seconds to 2" gives you something to judge. "Update the platform" does not. Approval should come from a business result, not because a design sounds advanced.

Founders often get pulled into stories about future scale. Engineers talk about ten times more traffic, multi-region failover, or splitting the app into services. Sometimes those risks are real. Often they are guesses dressed up as planning. Ask what limit you hit today, how often you hit it, and what it costs when it happens.

A few direct questions help:

• What customer or team problem hurts right now?
• What number should improve this quarter?
• What limit is real today, and what part is only a forecast?
• What happens if we do nothing for 90 days?

That last question is especially useful because it exposes urgency. If the honest answer is "not much," the design may solve a problem you do not have.

A good proposal stays close to the current business. If your startup needs faster releases and fewer incidents, the design should focus there. It should not wander into a full rebuild because "we may need it later."

The strongest proposals start small, tie the work to a current pain, and show a result you can check by the end of the quarter.

Look for deleted work

A good design should remove something, not just add more parts. When you read a proposal, ask a blunt question: what stops existing after this ships? If the answer is vague, the design may be bigger than the problem.

Deleted work is easy to miss because new work is more exciting to describe. Engineers explain the new service, the new database, or the new deployment flow in detail. They spend less time on what goes away. That is usually where time, risk, and money come back.

Ask for a before-and-after view. Which code paths disappear? Which manual steps no one has to do anymore? Which paid tools can you cancel? Which old services can the team shut down? A proposal that replaces three brittle scripts, one vendor bill, and a weekly support task can make sense even if it takes a month to ship.

The opposite pattern should make you nervous. If a plan adds a queue, a new API layer, another dashboard, and extra monitoring, but removes nothing, you are probably buying more complexity. Founders approve this kind of design all the time because it sounds safe for the future. In practice, the team now has more moving parts to test, pay for, and keep alive.

Take a simple example. A team wants to add an event bus between the app and billing system. That can be fine if it removes painful work such as manual billing retries, duplicate webhook handlers, or support tickets caused by sync errors. If the event bus sits on top of the old process and the old process stays in place, the team did not simplify anything.

Before approval, count what disappears. Count the services, tools, and manual tasks that go away. Count the vendor costs that end or shrink. Ask who will delete the old code and when. If nothing gets deleted, treat that as a warning.

Good architecture leaves the company with less to carry.

Price the tradeoffs

A proposal can look cheap because it hides most of the bill outside the build phase. Ask the team to split costs into two buckets: the one-time effort to ship it and the monthly cost to keep it running.

That second number changes fast once real traffic, logs, backups, alerts, and on-call support show up. A design that takes two weeks less to build can still cost much more every month if it adds heavy cloud usage or another vendor.

You do not need a perfect forecast. You need a rough 12-month model that shows where the money goes. Look at build time in engineer weeks, monthly cloud spend, vendor fees, support time after launch, and the expected cost of incidents and recovery work.

Support time gets ignored too often. If a new service needs constant tuning, extra dashboards, or weekend fixes, that labor is part of the price. Many founders approve proposals without pricing the human work that starts after release.

Migration costs belong in the same table. If the team needs to move data, rewrite old jobs, retrain staff, or run two systems at once for a month, count it. Training and handoff are real work.

Incidents also have a cost. More moving parts usually mean more failure points. Even if each outage lasts only 30 minutes, the team still loses time to investigation, rollback, customer support, and follow-up fixes.

A side-by-side comparison helps. Put the least expensive option for the next 30 days next to the least expensive option for the next 18 months. Sometimes those are the same choice. Often they are not.

A startup might choose a managed service because it ships faster. Early on, that can be the right call. But if the monthly fee climbs with every customer, while a simple in-house setup costs more once and much less to run, the proposal should show both paths clearly.

If an engineer cannot explain the tradeoffs in plain numbers, the design is not ready for approval. A good proposal does not stop at "what we should build." It also shows what you will pay now, what you will pay later, and who will carry that load.

Check the release impact

A design can look clean on paper and still slow the company down for months. Ask one question first: how does this change release speed over the next 30, 60, and 90 days? If the answer is "we need to pause feature work," treat that as a real cost.

Migration work always steals time from somewhere. Product may delay roadmap items. QA may test two paths at once. Support may handle edge cases from mixed old and new systems. Sales can feel it too if promised dates slip. A proposal should name those pauses clearly.

The first release needs a rollback plan before anyone merges code. If the new path fails, who turns it off, how long does that take, and what data might break? "We'll fix it fast" is not a plan. A safer proposal names the trigger for rollback, the owner, and the exact steps.

Small first releases win most of the time. Ship the new design behind a flag, move one narrow workflow, or route 5% of traffic first. It sounds less dramatic than a full rebuild, but it protects release rhythm and gives the team real feedback. Hidden rewrites often drag on, then land all at once with more risk than anyone expected.

A founder does not need to review every technical detail. You do need clear answers to four things:

• What slows down or stops during migration?
• How many releases does the change need before users feel the benefit?
• What is the rollback step for release one?
• What is the smallest version we can ship first?

When a proposal handles release impact well, the team keeps shipping while the design changes underneath. That usually beats a six-month rebuild that looks smart in a document and hurts the business every week it stays unreleased.

Review the proposal in order

Without a clear review order, architecture documents pull you into tools and diagrams before you know what problem the team is trying to fix.

Start with the problem statement and stop there for a minute. If that part is weak, the rest does not matter. A good proposal says what is broken now, who feels the pain, and what changes after the work ships.

Then review the rest in a simple sequence.

First, check the problem before the design. If the proposal says "scaling issues" or "future flexibility" without a real example, send it back. Ask what failed, how often, and what it cost last month.

Second, circle every assumption with no numbers. Claims like "this will speed up delivery" or "we need this for growth" need support. One rough estimate is better than a vague promise.

Third, ask for two versions. One can be the full design. The other should be smaller, cheaper, and faster to ship. Many teams jump to the big build when a narrow fix would solve most of the problem.

Fourth, request a one-page summary with cost, timing, main risks, and what the team will delay to do this work. If nobody can explain the plan on one page, the plan is still fuzzy.

Finally, set a decision point before approval. Define what would make you say yes, what would make you wait, and what facts you still need.

A simple example makes this clear. Imagine your team asks for a full event-driven rebuild because order processing feels slow. Before you approve it, ask a smaller question: are slow orders caused by architecture, or by one bad database query and missing alerts? That single question can save months.

Good senior engineers usually respond well to this kind of review. Clear questions force clear thinking. If you work with a Fractional CTO, ask them to translate the proposal into plain language and defend the smaller option too.

A simple startup example

Picture a B2B SaaS startup with one web app, one API, and one database. The product is growing, so a senior engineer proposes a big change: split the app into six services. On the diagram, it looks serious. Each service gets its own deploy flow, logs, alerts, and queue.

The proposal also adds more monitoring, more CI jobs, retry logic, and more deployment work. That sounds reasonable until you count the extra time. Two engineers can lose days every month just keeping the new setup stable.

The real problem is simpler than the design. Customers are not asking for six services. They are complaining because one report takes 18 seconds to load and exports fail when traffic spikes.

That redesign does not remove either pain on day one. It mostly creates more parts to run, more places for bugs to hide, and more release risk.

A smaller plan is often better. Keep the app together for now. Fix the slow query behind the report, add caching where it helps, move exports into a background job, and clean up the worst database bottleneck.

That can cut report time from 18 seconds to 3 and stop export failures without forcing the whole team to change how they build and ship software.

Then measure what still hurts. If exports keep growing faster than the rest of the app, split only that part later. At that point, the extra service has earned its place.

This is how big proposals fool founders. The larger design looks advanced, but the first release does not solve the current business problem. Ask one direct question: what pain disappears after this ships?

If the answer is vague, pause the approval. If the answer is specific and measurable, the design gets much easier to trust.

Mistakes founders make in these reviews

A founder often approves a proposal because the engineer sounds calm, certain, and senior. Confidence is not proof. Some of the weakest proposals look polished because they answer every question except the hard one: why is this the cheapest safe way to solve the problem now?

Diagrams also get too much credit. Boxes and arrows look impressive, but they hide the daily work that follows. Who will run it at 2 a.m. when a deploy fails? Who will update it, monitor it, pay for it, and explain it to the next hire? If the proposal adds three services, it also adds three new sources of noise, alerts, and drift.

Future-scale stories pull founders in for the same reason. "We will need this when we have 10 million users" sounds smart, but most startups are not there yet. Ask for numbers. How many users do you expect in the next 12 months? What breaks first? What does the simple version cost today, and when does it stop working? If nobody can answer that, the scale argument is mostly theater.

Another common mistake is skipping ownership. A design is not done when engineers merge the code. Someone has to own support, incident response, security patches, dashboards, backups, and ugly edge cases. If ownership is vague, the company pays for confusion later.

Rollback gets ignored for the same reason. Teams like talking about the new system, not the bad week after launch. Ask what happens if the release causes errors, slows down checkout, or breaks one customer segment. "We will fix it fast" is still not a rollback plan.

A short set of questions cuts through most of this:

• What work does this design remove?
• What will it cost each month in people and tools?
• Who owns it after launch?
• How do we roll back in one hour if it hurts the release?
• What numbers support the scale claim?

Founders do not need to win technical debates. They need to spot when a proposal makes the company busier, more fragile, and more expensive than the business can afford.

A quick approval check

A proposal can sound smart and still be a bad bet. Before you approve it, push it into plain language and simple numbers. If the team cannot answer these points clearly, the design is not ready.

Ask for the smallest version that can ship in 2 to 6 weeks. If the answer is a four-month build before users see anything, risk is already high.

Ask what work disappears right after release. Good design removes old code, manual steps, support burden, or repeated engineering chores. If nothing goes away, the new system may only add weight.

Ask what new monthly spend starts on day one. Count cloud services, vendor licenses, storage, logs, on-call time, and maintenance. A feature can look cheap during the build and stay expensive every month after.

Ask who handles incidents after launch. Name the person or team. If ownership is vague, response time will be vague too.

Ask for one metric that proves the change worked. Pick that number before the build starts. It could be deploy time, error rate, support tickets, conversion, or infrastructure spend.

This is where architecture proposals get easier to judge. You stop arguing about taste and start checking delivery, deleted work, ongoing cost, operational ownership, and proof.

What to do next

Do not approve a big design because the document looks polished or the engineer sounds sure. Ask for a rewrite in plain language first. If you cannot explain the plan back in simple words, the team should tighten the proposal before anyone commits time or money.

Ask for the options on one page, side by side. Each option should show the problem, the work it removes, the cost now, the cost later, and the effect on the next release. That format makes architecture proposals much easier to judge without getting lost in technical terms.

A strong rewrite usually includes a short summary in plain English, two or three options instead of one fixed answer, what existing work or systems can be removed, expected spend over the next few months, and the release effect on the next milestone.

If the numbers keep changing or the team cannot explain why one option is better, get a second review. A fresh technical reviewer can spot hidden complexity fast and tell you whether the team is buying speed, safety, or extra work you do not need.

That matters even more when the proposal touches infrastructure, data flows, AI tooling, or a core product rewrite. Those choices can lock in cost and process for a long time. A one-hour review now can save months of cleanup later.

If you want an outside read before approval, Oleg Sotnikov at oleg.is does this kind of work as a Fractional CTO and startup advisor. He helps founders compare tradeoffs, pressure-test assumptions, and translate technical proposals into plain business decisions.

Approve the design only when the team can answer a simple question: what do we get, what do we delete, what will it cost, and what happens to the release date?