Architecture and product audit · CHF 2’400
Before you spend CHF 30’000 building the wrong thing, buy the architecture first.
The architecture and product audit — the diagnostic — turns a fuzzy project or a fragile product into a decision document: the v1 boundary, the target architecture, build-vs-buy decisions, ranked risks, a phased plan and a budget range. It costs CHF 2’400, is ordered online with no mandatory sales call, is delivered in seven working days, and is 100% credited against the build if you sign an engagement within 60 days. You buy clarity, not a meeting.
Updated
In brief
- For whom
- A serious project before committing a build budget; or a live product that has to hold up
- Deliverable
- v1 boundary · target architecture · build vs buy · risk register · phased plan · budget range
- Duration
- Seven working days after access and the kickoff questionnaire are in
- Price
- CHF 2’400, paid when ordering — no hourly billing, no overrun
- Credit
- 100% deducted from a build signed within 60 days of delivery
- What follows
- A fixed-fee v1, an upgrade per scope, or nothing — the document stays yours
Most products that break do not break on a bug: they break on a data model laid down too fast, business logic scattered through the interface, payments whose state lives on the client, or a scope that was never written. These problems show in days when you know where to look — and cost months when you find them in production.
The audit is the short, honest version of what I do before every v1: read the business model, the workflows and the data, decide what is an engine, what is a screen and what is an integration, then write down what must exist — and in what order.
Order
100% credited against the build. CHF 2’400 otherwise.
You are not buying a sales call: you are buying clarity. If you then build with me within 60 days, the full CHF 2’400 comes off the build price — otherwise the document stays yours, usable by any engineer.
- Problem decomposition and a map of users and workflows
- Review of the current architecture (if a product exists)
- The v1 boundary: what is in, what waits, what will not exist
- Build-vs-buy decisions, service by service
- Target architecture: data, modules, integrations, operations
- Risk register, ranked by severity and cost to fix
- Phased implementation plan and a budget range per phase
- Price
- CHF 2’400, paid by card when ordering (Stripe). Invoice issued automatically.
- Timeline
- 7 working days after access and the kickoff questionnaire are in.
- Credit
- 100% of the price deducted from a build of at least CHF 20’000 signed within 60 days of delivery.
- Refund
- In full if I decline the engagement after reading your brief, or if you cancel before the kickoff call. After that, the work has started and the price is no longer refundable.
- Confidentiality
- Everything you share stays confidential; an NDA is signed on request before any code access.
01 — Scope
What the audit examines
Seven axes, in this order, because each one conditions the next.
- Business model and workflows
- Who pays, for what, when; the real processes behind the product and the ones still done by hand today.
- Data model
- Entities, properties, relations, what is immutable, what is versioned. The most expensive part to redo later — so the first one examined.
- Business logic
- Where the rules live — in a testable engine or scattered through components; what is deterministic, what should be.
- System boundaries
- What is the product, what is an integration, what should be a third-party service. The couplings that will block evolution.
- Payments, email, permissions
- Billing state, webhooks, idempotency; transactional sends; roles enforced server-side, data scoped per account.
- Operations
- Deployment, migrations, backups, observability, audit log — what is missing for an incident to be visible before the customer.
- Acquisition and measurement
- If the product is found through search: page structure, structured data, speed; and the events that measure the funnel.
02 — Deliverable
What you receive
A document, not a slide deck: the problem decomposition and a map of users and workflows; the v1 boundary — what is in, what waits, what will not exist; build-vs-buy decisions, service by service; the target architecture (data model, modules, integrations, operations); the risk register, ranked by severity and cost to fix; and a phased implementation plan with a budget range for each phase.
The document is written to be handed to any engineer, me included. It contains no recommendation that would only be justified if I build what follows.
03 — Method
How the audit runs
- Order and kickoff
- Ordered online, then within 24 business hours a kickoff message: the useful access, a short questionnaire, a slot for a 45-minute call.
- Access and reading
- Read access to the repo and the relevant accounts (database, payments, deployment); otherwise a guided demo and the existing documents.
- Examination
- The seven axes above, with precise questions as the reading goes — never a fifty-line questionnaire to fill in.
- Debrief
- The document on the seventh working day, then an hour to walk through it, challenge it and decide. Thirty days of replies within 24h afterwards.
04 — Where the method comes from
The architectures I have built
The audit grid is not a checklist from a book: it is what I apply to my own products. On Atamatax, a versioned tax situation engine, a document workflow and fixed-scope packages; on Horvera, a deterministic rules engine that shows its trace and its sources; on SponsorsMetrics, a third-party API data pipeline and a benchmark. The decisions and the mistakes behind these systems are detailed in Production Next.js architecture for a SaaS.
Is this the right service?
The audit makes sense if
- Your product is live and something worries you: slowness, incidents, a data model people work around, payments checked by hand.
- You have a serious concept and a budget to commit, but no written scope yet and no certainty about what is an engine and what is a screen.
- You must decide between rebuilding and continuing, and want a written opinion your team or another provider can pick up.
- The project-fit check pointed you to an audit first.
It is not the right service if
- The scope is written, the budget is set and the stage is clear — go straight to the production v1.
- You are looking for a security audit or a penetration test — that is the cybersecurity practice, on its own page.
- You want a second opinion on a framework choice with no product behind it — a call is enough, not an audit.
Proof — products I built and run
My own products, with their actual state. No client project is published yet.
- atamatax.comIn production · payments liveAtamatax — US expat tax infrastructureTax situation engine, document workflow, review before release, fixed-scope packages — the audit grid comes from this kind of system.Next.jsTypeScriptPostgresStripeVercelRead the case study →
- horvera.comIn production · payments liveHorvera — flight compensation infrastructureDeterministic, versioned rules engine, reference data shared with the programmatic pages — the example of business logic taken out of the interface.Next.jsTypeScriptPostgresStripePostHogRead the case study →
- sponsorsmetrics.comPrivate beta · design partners onboardingSponsorsMetrics — the pricing cockpit for YouTube talent agentsYouTube API pipeline, benchmark, read-only OAuth — the example of a data product and its boundaries.Next.jsTypeScriptPostgresYouTube APIVercelRead the case study →
How it works
Four steps, fixed scope, price agreed upfront.
- 01
Diagnose
20 minutes, free. Business model, workflows, risks and product scope. If I’m the wrong person, I say so.
- 02
Architect and propose
Within 48h: data model, system boundaries, integrations, UX — and one fixed fee with dated milestones. No “starting at”.
- 03
Build
4 to 6 weeks of controlled iterations. A demo every Friday on a Vercel preview. You watch the system grow live — no black box.
- 04
Launch
Payments, analytics, deployment, operational workflows. You leave with the repo, the accounts, the pipeline — and 30 days of 24h replies.
- 05
Improve
Measured iteration on real usage: a fresh fixed-fee scope per increment, or nothing if your team takes over. No hidden dependency.
Frequently asked questions
How much does an architecture audit cost?
CHF 2’400, fixed price, paid when ordering. No hourly billing, no overrun. If you then sign one of the three engagements within 60 days of delivery, the full CHF 2’400 is deducted from the build price.
How long does it take?
Seven working days between receiving access and the kickoff answers and delivering the document, with precise questions as the reading goes.
Can I get a refund?
Yes, in full, if I decline the engagement after reading your brief, or if you cancel before the kickoff call. After the kickoff call the work has started and the price is no longer refundable. The full terms are on the Terms page.
Do I need a call before ordering?
No. The diagnostic is ordered online; the kickoff call happens after the order. If you would rather describe the project first, the project form stays open and free.
Do I have to give access to the code?
Preferably — read-only, to the repo and the relevant accounts. Without access, the audit runs on a guided demo and the existing documents; the document says so and its conclusions are more cautious.
Does the audit commit me to building with you afterwards?
No. The document is written to be picked up by any engineer, and it contains no recommendation that would only hold if I build what follows. If a v1 or an upgrade makes sense afterwards, it is proposed at a fixed fee, separately — with the diagnostic price deducted.
Is it a security audit?
No. The audit covers basic application security — permissions, scoped data, secrets, validation — but a security audit or an authorised penetration test is a distinct service, described on the cybersecurity page.
Further reading
- Next.js architecture for a production SaaS: the decisions I make on every productWhat separates a Next.js project that holds from one that gets rewritten after a year comes down to about ten decisions. Here are mine, as applied on Atamatax, Horvera, Wabiro, SponsorsMetrics — and on this site.Next.js & full-stack9 minRead →
- Prototype or v1: the difference that decides your launchA prototype impresses in a demo. A v1 survives the first real customer. Confusing them is expensive.Building products5 minRead →
- When should a SaaS use AI? And when it absolutely should notI have built three decision engines in production — tax, air passenger law, scoring — and none of them uses a language model to decide. Here is the rule I apply, the cases where AI belongs, and why RAG is often the wrong answer.AI product engineering8 minRead →
Other services
- SaaS v1 developmentThe first version that survives its first customer — what it must contain, and what can wait.
- SaaS developerA complete SaaS product — auth, roles, data, payments, admin, deployment — built for its first real customer.
- Custom web applicationInternal tools, client portals, eligibility engines, back offices — the software that replaces the spreadsheet and the emails.
Decide on a document rather than a hunch?
CHF 2’400, seven working days, 100% credited against the build. Or describe the project first — it is free.
danilson.daveigaramos.pro@gmail.com · Reply within 24h, Mon–Fri.