01Overview
The group runs each purchase from the first contact to a signed agreement. Its platform keeps one record per person and reads the details out of uploaded documents, with the source of each. At every stage it shows which documents are still missing, and investors get a portal of the items approved for them.
The client file
One view of a person: their deals, documents, payments and identity.
The document reader
Every document recognised and filed, the key ones read, each value with its evidence.
The investor portal
Holdings, documents, payments and signatures, approved items only.
02The challenge
One client, several lists.
The same client could sit in several lists at once, as a lead, a contact and an investor. Documents were stored with no link to a deal or a person, and details were typed again from passports and agreements. “What is missing on this deal?” was a phone call, and investors had no single place to see what was theirs.
What the client wanted to achieve
One record per person
No client typed in twice.
No retyping
Details come out of the documents themselves.
Always know what’s missing
Each stage declares the documents it requires.
Nothing unapproved reaches an investor
The portal shows only what someone has approved.
How it worked before
- The same client in several lists
- Details typed again from IDs and agreements
- “What’s missing?” asked by phone
03How we built it
- 01
A platform from the client’s own specification
A detailed specification of the business became the base: permissions, an audit trail and an investor portal that shows approved items only.
- 02
Auditing what really ran
The tests passed, but the deployed settings had switched off uploads, automatic reading and every AI path. We found it and fixed it first.
- 03
One person, one record
Details are normalised, likely duplicates are flagged, and a person settles each merge. The database then refuses repeats.
- 04
Each market, its own stages
Stage sets, buyer types and the documents each stage requires. A deal cannot move on while a required document is missing.
- 05
Choosing the ID reader on real documents
Two readers compared on 18 real identity documents against answers a person had verified.
- 06
Reading with evidence
A value the reader is unsure of is never written. Each value it writes keeps its page and its exact words.
- 07
Sixteen acceptance checks, end to end
The whole path, from first contact to a signed agreement, checked against a live database.
01The platform
3 weeks02Audit and decisions
3 days03The core build
2 weeks04Acceptance
3 days
04How it works
Step 01Contact
One person, checkedA matching ID, email or phone is blocked; a matching name is flagged.Step 02Documents
Read in the backgroundAn upload returns at once and the reading finishes on its own.Every value sourcedIts page and words are kept; unsure values go to an exceptions list.Step 03Stages
What’s missingEach stage lists its required documents, and a business buyer needs more than a private one.Step 04Signing
Schedule to paymentsThe agreement’s schedule becomes tracked payments.The portalInvestors see approved items only.
Rules the platform keeps
- One record per person: a matching ID, email or phone is refused
- A deal cannot leave a stage while a required document is missing
- An unsure value is never written; it waits in the exceptions list
- Every failure has a named error, never a false success
- Investors see approved items only
05The outcome
Each purchase runs through one platform: one record per person, details read from the documents with their source, every stage showing what is still missing, and payments tracked from the signed schedule.
| Before | After |
|---|---|
| The same client in several lists | One record per person, duplicates blocked |
| Details typed again from IDs and agreements | Read from the document, each value linked to where it was read |
| “What’s missing?” asked by phone | Each stage lists the documents it still needs |
| Payment schedules kept inside documents | Tracked payments, in more than one currency |
| Updates sent to investors by hand | A portal that shows approved items only |
06Key figures
One document had no number; the dedicated reader correctly left it blank.
07Technology
What the system runs on, for the technical reader.
- Cloud
- AWSDocker
- AI
- A language model for classifying and reading documentsA dedicated identity-document reader
- Data
- PostgreSQLPrismaA job queue inside the database
- Documents
- Page renderingCheck-digit validationExtraction with evidence
- How we build
- Next.jsNestJSTypeScriptVitestPlaywright
08What comes next
Next, production keys, automatic deploys and backups, one run against the real reading services, then investor sign-in to the portal.
09About
About the client
A real estate investment group that buys across borders on behalf of its investors, each purchase running from the first contact to a signed agreement. We name a client only with their permission.
About MYBB
MYBB builds systems around how a business already works. We diagnose it with MYBB ROIQ, build the system, launch it with the team and keep running and improving it.