# The Pre-Build Technical Audit
## 27 checks to run before you approve a POS, CRM, or ERP build

By Tawfik Elsayed — Tech Lead, Fractional CTO, Senior Full-Stack Engineer
https://tawfikelsayed.tech · WhatsApp +966 54 162 8525
Updated September 2026

---

**How to use this:** score each check against the proposal or plan in front of you.
`Y` = evidenced in writing. `?` = claimed but not evidenced. `N` = missing.

Any `N` in section 1 or 3 is worth pausing the signature for.
Three or more `?` across the sheet usually means the vendor has not thought the build through yet.

---

## Section 1 — 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.

| # | Check | Score |
|---|-------|-------|
| 1 | Every screen and every user role is written down before pricing. | ___ |
| 2 | The current manual process is documented, including the exceptions. | ___ |
| 3 | Out-of-scope items are listed as explicitly as in-scope items. | ___ |
| 4 | Reporting requirements are defined by the person who will read the reports. | ___ |
| 5 | The data you already have is inspected before migration is priced. | ___ |
| 6 | Success is defined as a measurable operational outcome. | ___ |
| 7 | Phase one is small enough to be in production within 90 days. | ___ |
| 8 | Integrations are named, with their API documentation checked in advance. | ___ |
| 9 | Somebody on your side owns the project and can make decisions in a day. | ___ |

**Red flags:** a quote within an hour of first contact · no exclusions section ·
nobody asked how your team handles awkward cases today · "we will integrate with anything".

---

## Section 2 — 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.

| # | Check | Score |
|---|-------|-------|
| 10 | The stack choice comes with a written reason tied to your requirements. | ___ |
| 11 | The data model is drawn before development starts. | ___ |
| 12 | Multi-branch, multi-currency, and multi-user behaviour is decided up front. | ___ |
| 13 | Offline behaviour is specified for anything used at a counter or in the field. | ___ |
| 14 | Permissions and roles are modelled, not bolted on. | ___ |
| 15 | Audit trails exist for anything touching money or stock. | ___ |
| 16 | The mobile app and the web system share one backend and one source of truth. | ___ |
| 17 | A named senior engineer is accountable for architecture, not a rotating pool. | ___ |

**Red flags:** "it is what we use" as a stack rationale · no entity diagram at signing ·
offline mode unmentioned in a POS proposal · roles described only as "admin and user".

---

## Section 3 — 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.

| # | Check | Score |
|---|-------|-------|
| 18 | The source code sits in a repository you own, from day one. | ___ |
| 19 | You control the hosting, domain, and database credentials. | ___ |
| 20 | Automated backups exist, and a restore has been tested at least once. | ___ |
| 21 | There is a staging environment separate from production. | ___ |
| 22 | Critical flows have automated tests — payments, stock movement, permissions. | ___ |
| 23 | You see working software at least every two weeks. | ___ |
| 24 | The warranty period, its scope, and what falls outside it are written down. | ___ |
| 25 | Handover includes documentation, credentials, and a walkthrough recording. | ___ |
| 26 | Post-launch support and its cost are agreed before launch, not after. | ___ |
| 27 | You could replace the vendor next month without losing the system. | ___ |

**Red flags:** repository on the vendor's account · untested backups · one environment ·
documentation "in the code" · any hesitation when you ask check 27 out loud.

---

## Scoring

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

---

## If you want a second opinion

I review proposals, existing systems, and stalled builds as an independent Tech Lead
and fractional CTO. If your score came back uncomfortable, send me the proposal and
the score sheet — I will tell you which gaps actually matter for your situation.

- Book a call: https://tawfikelsayed.tech/contact-us
- WhatsApp: +966 54 162 8525
- More resources: https://tawfikelsayed.tech/resources

© Tawfik Elsayed. Share it freely with your team; please keep the attribution.