Review technical assumptions before every big quote

Why big quotes leak margin

Big software quotes often start with a clean number and end with far less profit than anyone expected. Usually, there isn't one dramatic mistake. Margin leaks through a stack of small assumptions: hosting that looked cheap before real traffic, APIs with usage fees, vendors with setup costs, and support work nobody priced.

That happens because early pricing often comes from speed, not proof. Sales wants an answer. Founders want to keep momentum. Engineers may not have checked traffic, storage, rate limits, security requirements, or who will handle user issues after launch. A quote can look safe on paper and still lose money once real users show up.

One missed service fee is enough to wreck the margin. Picture a customer portal quoted at $40,000 with a comfortable buffer. A week later, the client asks for single sign-on, file storage, audit logs, and two outside integrations that charge per request. Each item looks manageable on its own. Together, they can wipe out the profit before launch.

Support does even more damage because it never really stops. Many founders price design, build, test, and release, then treat support as a minor add-on. Real users don't behave like test users. They forget passwords, upload broken files, ask for role changes, and hit odd edge cases at the worst possible time. On a fixed-price project, every unplanned hour comes straight out of the margin.

The timing makes it worse. Teams often spot the gap after the quote is out, or after the contract is signed. At that point, changing the number feels awkward, and absorbing the cost feels easier. That's how a promising deal turns into months of busy work with little return.

A short technical review before a large quote goes out catches most of these leaks while the number can still change. Thirty minutes spent checking hosting, integrations, and support can save far more than days of cleanup later.

Which assumptions deserve a check

Every large software quote hides a few guesses. If those guesses are wrong, the team can still ship the project and still lose money.

Start with usage. A portal for 300 staff members costs one thing. A portal that needs to handle 30,000 customers, image uploads, and monthly spikes costs something else. User count, traffic peaks, file storage, and data retention can change hosting and database costs fast.

Then look at outside tools. A quote may seem fine until someone adds a payment provider, CRM sync, email service, analytics tool, or an API with per-request pricing. Per-seat plans creep up too. Ten internal users is one budget. Fifty support agents with paid seats is another.

Some costs don't look technical at first, but they still land on the team. Billing corrections, refunds, account changes, report exports, and data cleanup often need manual work. If nobody prices that work, it eats margin every week.

Most reviews should answer five plain questions: how many users the product really needs to support, which third-party tools charge per seat or per request, which business tasks still need human handling, how much support the team will provide after launch, and which security or compliance tasks the client expects.

Support is where many quotes go wrong. Teams price delivery and forget the steady work after launch: bug fixes, dependency updates, browser issues, failed imports, password resets, and weekend incidents. Even a simple product needs regular attention.

Security also needs a direct answer before pricing. Does the client need daily backups? How fast must recovery happen? Do they need audit logs, access rules, approval flows, or vendor security reviews? These aren't small extras. They shape both the build and the monthly bill.

Teams that right-size infrastructure early avoid a lot of expensive mistakes. That's why experienced CTOs push for a short assumption check before any large quote goes out. It doesn't take long, and it can protect startup quote margins better than a polished proposal ever will.

A short review before pricing

Most pricing mistakes happen before anyone writes code. They start with quiet guesses about usage, integrations, and support. A short review works best when it stays simple.

Use day-one usage, not the dream version of the product. If the customer will launch with 300 users, one admin team, and a small set of reports, price that reality first. A quote built around future scale can scare the buyer away. A quote built on wishful low effort can hurt you just as fast.

Then list every system that has to connect. Don't stop at labels like "CRM" or "payment gateway." Name the actual tools, who owns access, and what data has to move between them. Hosting and integration costs often rise because a team says "simple API" before anyone checks auth rules, rate limits, bad data, or missing docs.

A good one-page review usually includes the expected users, traffic, and data volume for the first 90 days; every outside system and the person who can provide access; who handles support after launch and how many hours that may take; what sits inside the fixed price and what does not; and a short list of assumptions nobody has proven yet.

Support needs a clear owner. If imports fail, passwords break, or sync jobs stop overnight, somebody will spend time fixing it. If you leave support costs in software projects out of the quote, the work still happens. It just lands on your team for free. Even a simple cap such as "includes up to 10 hours in the first month" gives the number some protection.

Scope also needs hard edges. "Customer portal" sounds tidy until the buyer asks for role rules, audit logs, notifications, and reporting. Some of that may belong in the base quote. Some should wait for a later phase. If you don't mark the line, the line moves.

Write open assumptions in plain language. "The client will provide clean data." "Their SSO team will respond within two days." "The app can run on one server at launch." This is the kind of pass a founder pricing review should force before approval. Ten honest lines under a quote can protect more margin than ten polished slides.

Hosting questions that change the number

Hosting looks cheap when a team prices one quiet weekday. Real bills come from the busiest hour. If 300 people log in after an email campaign or a partner launch, the system has to stay fast then, not on an average Tuesday.

Ask for peak traffic estimates, even rough ones. You don't need perfect forecasting. You need a sane range for concurrent users, API calls, background jobs, and file uploads. A quote based only on average usage often survives on paper and breaks your margin in month two.

Storage is another quiet cost that grows fast. Teams count the app database and forget uploads, exported files, logs, screenshots, audit trails, and backups. A portal that stores signed PDFs, images, and activity logs can start small and triple its storage bill within a few months.

A few direct questions usually change the number. What's the busiest hour the system needs to handle without slowdowns? How much file storage will users add each month? Do you need separate test and staging environments, or only production at first? Who pays for backups, monitoring, and alerting from day one?

Test and staging environments deserve a real decision. Many founders assume one live environment is enough. Then the team asks for staging before launch, a QA setup, and maybe a demo environment for sales. That can double or triple part of the monthly infrastructure cost.

Backups, monitoring, and alerts should never sit outside the quote. They aren't extras. If the product matters to the client, someone needs database backups, uptime checks, error tracking, and alerts that reach a real person. Without that line item, support turns into unpaid cleanup.

A simple rule helps: price the system you need on a bad day, not the one you need on a calm day. That catches a lot of hidden hosting and integration costs before the quote goes out.

Integration questions teams skip

Teams often treat integrations like a small line item. They rarely are. One missing detail in an API, billing rule, or account setup step can turn a healthy quote into a thin one.

A promise like "we can connect to your CRM" sounds simple until someone checks what that actually means. Does the API support the action the client wants, or does it only expose read-only data? Docs can look fine and still hide limits that appear once real traffic starts.

Before you price the work, test one real path end to end. Pull one record, update one field, trigger one event. That quick check usually tells you more than an hour of reading docs.

What to verify early

Review the parts that usually create extra work: whether the required API methods actually exist in a test account, whether rate limits or webhook delays will force queueing and background jobs, who pays for third-party usage and extra seats, and who will provide admin access, tokens, sandbox accounts, and vendor approvals.

Rate limits change the build more than founders expect. If an API allows only a small number of requests per minute, your team may need caching, batching, or sync jobs. That's real work, and it belongs in the quote.

Webhook behavior causes trouble too. Some services deliver events late. Some send duplicates. Some stop sending if your endpoint fails too often. If your product depends on fast updates, you may need retries, logs, and a fallback sync. Hours disappear quickly here.

Third-party costs are another common miss. A client may assume your price includes usage fees from the billing provider, mapping service, or document signing tool. If the contract doesn't name who pays, your project carries that risk.

Admin access can stall a project for days. Teams quote the coding work, then wait on token approval, security review, or account ownership questions. A realistic quote includes time for setup, testing, and a few rounds of access trouble.

A small integration check before a big quote saves more than it costs. It also keeps awkward re-pricing calls off your calendar.

Support work founders forget to price

Most founders price the build and maybe a bit of testing. The support load often stays off the quote, even though it starts on day one. That gap eats margin fast.

User questions take more time than they seem to. A customer says "the app is broken," but someone still has to reply, reproduce the issue, check logs, decide whether it's a bug or a setup problem, and send the next step. Even a simple app can create a steady stream of small tickets.

Bug triage costs real engineering time too. Developers stop planned work, gather details, check recent changes, and decide how urgent the fix is. If the quote assumes the team only builds features, the math is already wrong.

Release work gets missed all the time. After each deployment, someone should check the basics: login, signup, payments, email, imports, and any admin actions customers use every day. Those checks may take 20 to 40 minutes per release, and more if the product has several user roles.

Some support cases come up again and again: failed payments that lock users out by mistake, CSV imports with bad headers or broken dates, duplicate accounts, password resets, and customer data fixes after a bad sync or mistaken delete. These aren't rare edge cases. They are normal operating costs.

Response times matter as much as ticket volume. If sales promises a reply in two hours, you need staff ready to meet that promise. If the team can only answer the next business day, put that in the quote and in the agreement. Customers will ask anyway. It's better to set the rule before go-live than argue after the first urgent email.

This is one area where an outside technical review can pay for itself. Oleg Sotnikov, the advisor behind oleg.is, often helps teams turn vague support expectations into a simple operating model: who answers first, what gets escalated, what is included, and what becomes paid extra work. That kind of clarity makes quotes more honest and keeps small issues from turning into unpaid weekly chores.

A realistic example: quoting a customer portal

A sales team promises a customer portal in six weeks. The portal sounds simple: users log in, upload files, download invoices, and pay online. The first quote looks healthy, so everyone relaxes.

Then the missing work shows up.

The quote includes app screens and basic backend work, but it skips three costs that almost always appear. File uploads need storage, bandwidth, virus scanning, and rules for large files. Billing needs support for failed charges, refunds, invoices, and customer questions. Email notifications need a sender service, template setup, bounce handling, and a plan for password resets.

None of these items looks dramatic alone. Together, they eat the margin.

A short review changes the estimate quickly. The team adds monitoring so they can spot failed uploads and payment errors before customers complain. They add retries for webhooks and email jobs because third-party systems fail in normal use. They add a small admin area so staff can resend invoices, unlock accounts, check upload status, and fix common issues without waiting on developers.

That admin area often saves more time than founders expect. If support has no tools, every billing issue becomes an engineering task. A five-minute customer fix can turn into two hours of developer time.

Now the quote is higher, but it's honest. The team prices the real work: cloud storage, email delivery, payment edge cases, support flows, logging, and the internal screens people need after launch. The number may rise by 20 to 30 percent, yet the project is much safer.

That's the difference between winning a deal and keeping the margin. A neat demo sells the portal. The plain, unglamorous parts keep it alive once customers start using it.

Common mistakes during quote review

Most margin leaks start with work that looked small on day one. A team sees "just one more integration" and prices it like a simple API call. Then they find rate limits, bad docs, odd auth rules, edge cases, and a week of testing nobody planned for.

Founders hit the same problem with infrastructure. Early cloud estimates often look calm because traffic is low, logs are short, and storage is cheap at first. After launch, usage grows, background jobs pile up, and costs rise in places people barely noticed during the quote.

Support is another quiet problem. Some teams leave it out of the number and assume they'll sort it out later. That only works if the quote says so clearly. If the client thinks bug fixes, user questions, and minor changes are included, the project starts losing money as soon as people begin using it.

Internal staff tools get missed more often than founders expect. A customer-facing product may also need an admin panel, support dashboard, audit logs, user permissions, and simple export tools. None of that feels dramatic, but staff use these screens every day, and building them takes real time.

Vendor promises trip people up too. Sales pages make setup sound easy. In practice, a payment tool, CRM, or identity provider may have limits that only show up in a real test. If nobody checks the actual workflow before pricing, the quote rests on guesses.

A good review should pressure-test a few basic points: whether each integration has a proven test instead of a doc page, whether hosting still makes sense after launch month, whether the quote states what support includes, and whether staff need internal workflow tools from day one.

When founders check these assumptions before approval, they usually find at least one soft spot. Fixing it before the proposal goes out is cheap. Fixing it after the contract is signed is where margins disappear.

Quick checks before approval

A founder should review technical assumptions before every big quote, even when the team already estimated the work. This last pass isn't about mistrust. It's about catching small misses that turn into thin margins a month later.

Most quote problems come from simple gaps. Someone forgets a paid service. Someone assumes low traffic. Someone thinks support will "just fit" into the team's week. Those misses look small on paper, then pile up after launch.

Before you approve the number, ask for direct answers. Can the team name every paid service, including hosting, email, logging, storage, third-party APIs, and admin tools? If usage doubles in the first month, does the quote still leave room for profit? Who owns support, monitoring, backups, and incident response after launch? Did the team write exclusions in simple language the client can understand? And if one surprise shows up - a harder integration or extra support hours - would you still accept the margin?

If the team can't answer those questions quickly, the quote isn't ready. You don't need a perfect forecast. You need a quote that can survive normal uncertainty.

One detail founders often skip is ownership. "The team" isn't an owner. Name a person. If nobody owns support, alerts, backups, and customer issues, those jobs land on whoever is awake when something breaks. That's expensive, and it burns trust fast.

Exclusions also need plain words. Don't hide them in vague estimate notes. Say whether the quote includes data migration, third-party setup, after-hours support, security review, or staff training. Clients usually accept limits when you state them early. They get upset when they learn about them later.

A review like this can take 10 minutes. It can save weeks of unpaid cleanup. If the number only works when nothing goes wrong, it's too low.

What to do next before you commit

Before you approve a large estimate, pause for a short review. Ten or fifteen minutes can save months of margin loss. The goal is simple: check the assumptions that make the number look safe.

You don't need to re-architect the whole project. You need a short pass over hosting, third-party integrations, support load, and any work the team marked as "standard" without much detail. That's often where the real cost hides.

Write down the answers and keep them with the estimate and scope. If the quote changes later, you'll be able to see why. It also helps during customer calls. When someone asks why the price moved, your team can point to a real assumption instead of giving a vague answer.

This habit matters even more when the team feels pressure to close fast. A rushed quote often looks profitable on paper and weak in practice. One missed API limit, one underpriced support promise, or one wrong hosting assumption can wipe out the profit.

If your team doesn't have much pricing depth, bring in outside technical judgment before you sign off. A fractional CTO can spot weak assumptions quickly because they've seen the same mistakes across many projects. That's usually cheaper than fixing a bad deal after the contract starts.

If you need that second look, Oleg Sotnikov at oleg.is reviews architecture, infrastructure choices, and operating costs before teams commit. It's most useful when the quote is large, the scope is still moving, or the delivery team seems a little too confident for the amount of unknowns on the page.