---

title: "Before asking for a software estimate, prepare these seven things" slug: client-education-pre-estimate-checklist pillar: Client Education angle: checklist audience: First-time buyers, agency partners status: draft

Before asking for a software estimate, prepare these seven things

What an engineer needs from you before they can give a number that will not change three weeks into the project.

Software estimates are not guesses. They are calculations based on assumptions — and the more assumptions a developer has to make because you have not specified something, the higher the padding in the number they give you, and the more likely the actual cost will exceed it. An estimate built on complete information is more accurate, more honest, and more useful to both parties than a quick number given on incomplete inputs.

This checklist was built by observing what information actually changes the shape of a TypeScript API project. Every item on it is tied to a real decision that affects architecture, timeline, or cost. Work through it before the first technical conversation and you will get a better estimate, fewer surprises, and a faster start.

The problem this checklist exists to prevent

The problem is not that developers give wrong estimates. It is that they often estimate the application they imagine from partial information, not the application the client actually needs. The gap between the two shows up as scope changes mid-project, which means change orders, extended timelines, or features quietly dropped to hit a deadline.

A client who says "we need a user management system" has given the developer very little to work with. Do users log in with passwords, magic links, or passkeys? Do they have roles? Are there multiple organisations (tenants) with separate user spaces? Is there SSO for enterprise customers? Can admins impersonate users for support purposes? Each of these answers routes to a different module, a different set of dependencies, and a meaningfully different cost.

The seven items below are the questions that most reliably separate an accurate estimate from one that will grow.

Who this checklist is for

First-time technical buyers, product managers commissioning a custom build, and agency partners who are collecting a quote on behalf of a client. If you have never shipped a production API, most of these items will require a short conversation with your developer before you can answer them. That is the conversation to have before the estimate, not after.

If you are an experienced technical buyer, this checklist will confirm what you already know. The value is having it as a structured document to share with a client who is less technical.

The list

1. Authentication: list every way a user should be able to log in.

Password login, magic link, Google OAuth, GitHub OAuth, SSO (SAML or OIDC for enterprise), passkeys (biometric / hardware key), or some combination. Each of these is a separate module with separate dependencies, separate configuration keys, and separate UI flows. A TypeScript API boilerplate that handles auth seriously has at minimum four separate auth sub-modules:

modules/auth/
modules/auth_saml/
modules/auth_sso/
modules/auth_impersonation/

If you are not sure which you need: password login is the default; Google OAuth is the most common addition; SAML is required for enterprise clients who use Okta or Azure AD. Passkeys are a UX improvement that requires a WebAuthn implementation, which is non-trivial. Each one you add extends the estimate.

2. Multi-tenancy: do different organisations have separate data, or is all data shared?

A multi-tenant application is structurally different from a single-tenant one. If the answer is "companies sign up and each company's users can only see their company's data," that is multi-tenancy, and it touches every data model in the application. A boilerplate that handles multi-tenancy has a tenant cluster with at minimum:

modules/tenant/
modules/tenant_member/
modules/tenant_setting/
modules/tenant_subscription/
modules/tenant_usage/
modules/tenant_invitation/
modules/tenant_branding/
modules/tenant_domain/

Eight modules. If this is in scope and not on the estimate, the estimate is wrong. If it is out of scope and comes up after the project starts, it is a significant change order.

3. File storage: what files will users upload, and where should they live?

"Users can upload files" is incomplete. The developer needs to know: what file types (images only, or documents, or videos?), what size limits, whether files are public or private, and whether storage goes to AWS S3, Cloudflare R2, DigitalOcean Spaces, or a self-hosted solution.

The storage module in a production API handles multiple providers because different clients have different requirements:

// modules/storage/storage.enums.ts
export const StorageProviderTypeSchema = z.enum([
  'aws-s3', 's3', 'cloudflare-r2', 'digitalocean-spaces', 'minio'
])

export const StorageFolderSchema = z.enum([
  'general', 'categories', 'users', 'posts', 'projects',
  'images', 'videos', 'audios', 'files', 'content',
  'branding/logos', 'branding/favicon', 'branding/wallpapers',
])

If you do not specify, the developer will assume the simplest configuration and charge to change it later when you do.

4. Notifications: which channels do you need, and for which events?

Email is usually a given. Push notifications (mobile), SMS, and in-app notifications (the bell icon) are separate systems with separate provider integrations, separate configuration, and separate cost. A production boilerplate separates them cleanly:

modules/notification_mail/
modules/notification_push/
modules/notification_sms/
modules/notification_inapp/

For each channel, the developer also needs to know which events trigger a notification — account creation, password reset, payment confirmation, invitation accepted, etc. "Send notifications" is not a specification. "Send an email when a user is invited and an in-app notification when the invitation is accepted" is.

5. Payments: specify the exact model, not the general goal.

"Accept payments" covers at least four meaningfully different systems: one-time purchases, subscriptions with recurring billing, usage-based billing (charge for API calls or seats), and marketplace payments (platform takes a cut of transactions between parties). A production boilerplate treats these as distinct domains:

modules/payment/
modules/coupon/
modules/tenant_subscription/
modules/tenant_usage/

Each one has its own data model, its own provider integration (Stripe, Paddle, LemonSqueezy), and its own edge cases. If you say "we want to add subscriptions later," that later has a real cost to retrofit. If it is in scope from day one, the estimate should include it.

6. Third-party integrations: list everything the application needs to talk to.

This includes: payment providers, email providers (SendGrid, Resend, Mailgun), SMS providers, push notification services (FCM, APNs), analytics, CRM, ERP, external APIs. Each integration is a mini-project: authentication, error handling, webhook receiving or sending, and retry logic. The webhook module in a production API handles outbound webhooks from the application to external systems:

modules/webhook/
modules/api_key/
modules/user_social_account/

API keys (for third parties calling your API), social account connections (OAuth-linked accounts beyond login), and webhook configuration are each separate modules. List every external system you know about. The estimate for "two integrations" and "seven integrations" are not the same number.

7. Reporting and data export: what does "admin sees the data" mean?

Viewing data is design work and read-query work. Exporting data is file generation work. Audit logs are a compliance requirement that affects every write operation in the system. These are three different features that sound like one:

modules/audit_log/
modules/tenant_export/
modules/tenant_usage/

If you need GDPR-compliant data export (users can request all their data), that is a specific feature with a specific format and a specific response time requirement. If you need audit logs for compliance reasons, every mutation in the system needs to write an audit record. Neither is free to add retroactively.

A worked example using the target repo

Take a project described as: "B2B SaaS platform where teams can log in and manage their projects."

Walking the checklist against the boilerplate's module structure:

• Auth: teams suggests SSO (enterprise clients use Okta) → auth_saml or auth_sso in scope
• Multi-tenancy: "teams" is a tenant model → the full tenant cluster (8 modules) is in scope
• Storage: "manage projects" likely includes file attachments → storage with S3 or equivalent in scope
• Notifications: team invitations and project updates suggest email at minimum → notification_mail in scope; push and SMS probably out of scope for v1
• Payments: "B2B SaaS" strongly implies subscriptions → tenant_subscription in scope from day one
• Integrations: not stated, but B2B clients often need Slack notifications or CRM sync → a list of integrations is needed before estimating
• Reporting: admin teams need usage data → tenant_usage in scope; data export probably required for enterprise clients

Before this checklist: "B2B SaaS with team management" could be estimated as a 10-week project. After it: the same description is more accurately estimated at 18-22 weeks because the full scope is visible. The number is larger, but it is honest.

What is deliberately not on the list and why

UI/UX design is not here because it is a separate engagement that happens before or in parallel with development, not a prerequisite for an accurate API estimate. The API estimate should be independent of whether design is complete.

Performance requirements (specific throughput targets, latency SLAs) are not here because they rarely change the architecture at the estimate stage — they change the infrastructure and optimisation work later. Flag them if you have them; they do not block the initial estimate.

Exact technology choices are not here because the developer should make those recommendations based on your answers to the seven items above, not receive them as requirements from a client who may not have the context to make the tradeoff correctly.

CTA

Take this list to your next project brief and fill in one answer per item. You do not need precise answers — "probably Google OAuth plus password, not sure about SSO" is more useful than leaving auth blank. Send the completed list to your developer before the estimate call. The call will be shorter, the number will be more accurate, and the project will start on shared assumptions rather than optimistic ones.

Trade-off

A more complete specification takes longer to produce. A client who wants a number in twenty-four hours cannot complete this checklist in twenty-four hours. The trade-off is between a fast rough estimate and a slower accurate one. For projects under four weeks of work, a rough estimate is usually fine. For projects over eight weeks, the cost of an inaccurate estimate — in change orders, relationship friction, and delayed delivery — consistently exceeds the cost of a proper discovery phase.

Business impact

Estimates built on complete information reduce the two most common failure modes in custom software projects: scope creep that surprises the client, and scope creep that surprises the developer. When both parties have agreed on the same specification before work starts, every addition is a visible change rather than a contested expectation. That visibility protects the client's budget and protects the developer's time.

The seven-item checklist is not a contract. It is a starting point for the conversation that a contract should be built on.

What to do next

Send this checklist to the next client who asks for an estimate before specifying. Ask them to fill in one paragraph per item — rough, directional answers are fine. Schedule a thirty-minute call to review their answers together. That thirty minutes is the fastest path to an estimate both parties can commit to.