Free resource · 9 min read

The Pre-Build Technical Audit

27 checks to run before you approve a POS, CRM, or ERP build

A senior-engineer checklist for founders and operations leads. Run these 27 checks on any proposal, agency, or in-house plan before money moves. Most failed builds break on items 1-9, long before a line of code is written.

Email me the fillable copies Read all 27 checks

Written by Tawfik Elsayed, Tech Lead and fractional CTO for six companies · Updated September 2026

Section 1 · 9 checks

Scope and requirements

Nine of ten disputes I am called into trace back to this section. Scope defects are cheap now and ruinous in month four.

1
Every screen and every user role is written down before pricing.
Price without a screen list is a guess, and guesses get corrected upward mid-build.
Red flag: A quote arrives within an hour of your first message.
2
The current manual process is documented, including the exceptions.
Software fails on the exceptions — the manual override, the walk-in customer, the returned item.
Red flag: Nobody asked how your team handles the awkward cases today.
3
Out-of-scope items are listed as explicitly as in-scope items.
What is excluded is where change requests are born.
Red flag: The proposal has no exclusions section at all.
4
Reporting requirements are defined by the person who will read the reports.
Reports designed by developers get rebuilt after launch, at your cost.
Red flag: Reporting is one bullet point saying "dashboards and reports".
5
The data you already have is inspected before migration is priced.
Legacy data is always messier than described, and cleaning it is real engineering work.
Red flag: Migration is quoted as a fixed line item without anyone opening your existing data.
6
Success is defined as a measurable operational outcome.
"A modern system" cannot be delivered or disputed. "Closing day-end in under 10 minutes" can.
Red flag: Nobody can tell you how you will know the project worked.
7
Phase one is small enough to be in production within 90 days.
Long first phases hide problems until the budget is spent.
Red flag: The first delivery date is more than a quarter away.
8
Integrations are named, with their API documentation checked in advance.
Payment gateways, accounting systems, and government portals routinely lack the endpoint you assumed.
Red flag: "We will integrate with anything" appears in the proposal.
9
Somebody on your side owns the project and can make decisions in a day.
Vendor delay is usually your delay: decisions waiting on an unavailable stakeholder.
Red flag: The project owner is the busiest executive in the company.

Section 2 · 8 checks

Architecture and technical decisions

You do not need to evaluate the code. You do need evidence that the decisions were made deliberately, by someone senior enough to defend them.

10
The stack choice comes with a written reason tied to your requirements.
Teams default to whatever they used last, which may not survive your concurrency, offline, or reporting needs.
Red flag: The reason given is "it is what we use".
11
The data model is drawn before development starts.
Schema mistakes are the single most expensive class of rework in POS, CRM, and ERP systems.
Red flag: No entity diagram or table list exists at contract signing.
12
Multi-branch, multi-currency, and multi-user behaviour is decided up front.
Retrofitting these into a single-branch system is close to a rewrite.
Red flag: "We can add branches later" with no schema evidence.
13
Offline behaviour is specified for anything used at a counter or in the field.
A POS that stops when the internet does will be abandoned by your staff within a week.
Red flag: Offline mode is not mentioned in a POS or field-app proposal.
14
Permissions and roles are modelled, not bolted on.
Role logic sprayed across a codebase becomes the source of both bugs and audit failures.
Red flag: Roles are described only as "admin and user".
15
Audit trails exist for anything touching money or stock.
Without an immutable record, disputes with staff, suppliers, and auditors are unresolvable.
Red flag: No mention of logging who changed what and when.
16
The mobile app and the web system share one backend and one source of truth.
Two backends means two versions of the truth and permanent reconciliation work.
Red flag: The app is quoted by a separate team with its own database.
17
A named senior engineer is accountable for architecture, not a rotating pool.
Architecture by committee produces a system nobody can explain six months later.
Red flag: You cannot get the name and background of the technical lead.

Section 3 · 10 checks

Delivery, quality, and handover

This section decides whether you own an asset at the end or rent a dependency. Insist on it before signing, never after.

18
The source code sits in a repository you own, from day one.
Code delivered as a zip file at the end is leverage held over you until then.
Red flag: The repository is on the vendor account with no access for you.
19
You control the hosting, domain, and database credentials.
Credential lock-in is the most common way a routine dispute becomes an outage.
Red flag: The vendor "manages everything" and cannot list what you own.
20
Automated backups exist, and a restore has been tested at least once.
An untested backup is a belief, not a backup.
Red flag: Backups are described but never demonstrated.
21
There is a staging environment separate from production.
Testing changes on live data is how businesses lose a day of sales.
Red flag: One environment, and deployments happen "carefully".
22
Critical flows have automated tests — payments, stock movement, permissions.
Manual testing does not survive contact with the fifth feature request.
Red flag: Testing is entirely manual and entirely at the end.
23
You see working software at least every two weeks.
Long silences are where projects quietly go wrong.
Red flag: The next demo is at the end of the project.
24
The warranty period, its scope, and what falls outside it are written down.
Otherwise the definition of "bug" is negotiated when you are least able to negotiate.
Red flag: "We fix bugs" with no period, scope, or response commitment.
25
Handover includes documentation, credentials, and a walkthrough recording.
The next developer costs three times as much without them.
Red flag: Documentation is "in the code".
26
Post-launch support and its cost are agreed before launch, not after.
Support priced after go-live is priced against your dependency.
Red flag: Support is "we will discuss it later".
27
You could replace the vendor next month without losing the system.
This is the single best test of every item above. If the answer is no, one of them failed.
Red flag: Any hesitation when you ask this question directly.

Scoring your proposal

24–27 metProceed. This is a well-prepared build.
18–23 metProceed after closing the gaps in writing, as contract amendments.
12–17 metDo not sign yet. Get a second technical opinion first.
Below 12The plan is not ready. Fixing it now costs a fraction of fixing it in month four.

Want the fillable copies?

The checklist, the one-page scope brief, and the vendor scorecard — sent to your inbox so you can score a real proposal against them. No sequence, no newsletter.

Or take the files directly

No email required. Nothing here is gated.

Score came back uncomfortable?

Send me the proposal and your score sheet. I will tell you which gaps actually matter for your situation, and which are fine to accept — the same read I give the companies where I hold the Tech Lead seat. No charge for a first look.

Send me the proposal Ask on WhatsApp

Want the ongoing version of this? See how a fractional CTO engagement works.

The Pre-Build Technical Audit

27 checks to run before you approve a POS, CRM, or ERP build

Written by Tawfik Elsayed, Tech Lead and fractional CTO for six companies · Updated September 2026

Section 3 · 10 checks

Delivery, quality, and handover

This section decides whether you own an asset at the end or rent a dependency. Insist on it before signing, never after.

18
The source code sits in a repository you own, from day one.
Code delivered as a zip file at the end is leverage held over you until then.
Red flag: The repository is on the vendor account with no access for you.
19
You control the hosting, domain, and database credentials.
Credential lock-in is the most common way a routine dispute becomes an outage.
Red flag: The vendor "manages everything" and cannot list what you own.
20
Automated backups exist, and a restore has been tested at least once.
An untested backup is a belief, not a backup.
Red flag: Backups are described but never demonstrated.
21
There is a staging environment separate from production.
Testing changes on live data is how businesses lose a day of sales.
Red flag: One environment, and deployments happen "carefully".
22
Critical flows have automated tests — payments, stock movement, permissions.
Manual testing does not survive contact with the fifth feature request.
Red flag: Testing is entirely manual and entirely at the end.
23
You see working software at least every two weeks.
Long silences are where projects quietly go wrong.
Red flag: The next demo is at the end of the project.
24
The warranty period, its scope, and what falls outside it are written down.
Otherwise the definition of "bug" is negotiated when you are least able to negotiate.
Red flag: "We fix bugs" with no period, scope, or response commitment.
25
Handover includes documentation, credentials, and a walkthrough recording.
The next developer costs three times as much without them.
Red flag: Documentation is "in the code".
26
Post-launch support and its cost are agreed before launch, not after.
Support priced after go-live is priced against your dependency.
Red flag: Support is "we will discuss it later".
27
You could replace the vendor next month without losing the system.
This is the single best test of every item above. If the answer is no, one of them failed.
Red flag: Any hesitation when you ask this question directly.

Score came back uncomfortable?

The Pre-Build Technical Audit

Scope and requirements

Every screen and every user role is written down before pricing.

The current manual process is documented, including the exceptions.

Out-of-scope items are listed as explicitly as in-scope items.

Reporting requirements are defined by the person who will read the reports.

The data you already have is inspected before migration is priced.

Success is defined as a measurable operational outcome.

Phase one is small enough to be in production within 90 days.

Integrations are named, with their API documentation checked in advance.

Somebody on your side owns the project and can make decisions in a day.

Architecture and technical decisions

The stack choice comes with a written reason tied to your requirements.

The data model is drawn before development starts.

Multi-branch, multi-currency, and multi-user behaviour is decided up front.

Offline behaviour is specified for anything used at a counter or in the field.

Permissions and roles are modelled, not bolted on.

Audit trails exist for anything touching money or stock.

The mobile app and the web system share one backend and one source of truth.

A named senior engineer is accountable for architecture, not a rotating pool.

Delivery, quality, and handover

The source code sits in a repository you own, from day one.

You control the hosting, domain, and database credentials.

Automated backups exist, and a restore has been tested at least once.

There is a staging environment separate from production.

Critical flows have automated tests — payments, stock movement, permissions.

You see working software at least every two weeks.

The warranty period, its scope, and what falls outside it are written down.

Handover includes documentation, credentials, and a walkthrough recording.

Post-launch support and its cost are agreed before launch, not after.

You could replace the vendor next month without losing the system.

Scoring your proposal

Score came back uncomfortable?

The Pre-Build Technical Audit

Scope and requirements

Every screen and every user role is written down before pricing.

The current manual process is documented, including the exceptions.

Out-of-scope items are listed as explicitly as in-scope items.

Reporting requirements are defined by the person who will read the reports.

The data you already have is inspected before migration is priced.

Success is defined as a measurable operational outcome.

Phase one is small enough to be in production within 90 days.

Integrations are named, with their API documentation checked in advance.

Somebody on your side owns the project and can make decisions in a day.

Architecture and technical decisions

The stack choice comes with a written reason tied to your requirements.

The data model is drawn before development starts.

Multi-branch, multi-currency, and multi-user behaviour is decided up front.

Offline behaviour is specified for anything used at a counter or in the field.

Permissions and roles are modelled, not bolted on.

Audit trails exist for anything touching money or stock.

The mobile app and the web system share one backend and one source of truth.

A named senior engineer is accountable for architecture, not a rotating pool.

Delivery, quality, and handover

The source code sits in a repository you own, from day one.

You control the hosting, domain, and database credentials.

Automated backups exist, and a restore has been tested at least once.

There is a staging environment separate from production.

Critical flows have automated tests — payments, stock movement, permissions.

You see working software at least every two weeks.

The warranty period, its scope, and what falls outside it are written down.

Handover includes documentation, credentials, and a walkthrough recording.

Post-launch support and its cost are agreed before launch, not after.

You could replace the vendor next month without losing the system.

Scoring your proposal

Score came back uncomfortable?