BEDFORDVIEW, GAUTENG, SOUTH AFRICA

Custom internal software for firms that have outgrown the spreadsheet.

I build project registers, compliance trackers, dashboards, and the integrations that get two systems talking to each other. I build for architecture, engineering and construction firms, because that is the industry I work in every day. I scope these to go live in four to six weeks. I also help practices use AI in their own work without putting client information somewhere they cannot get it back.

START A CONVERSATION SEE WHAT I BUILD

I have spent years working inside a healthcare architecture practice as a BIM developer, and I consult on information security alongside that. So I know how a practice like yours actually runs, and I know what tends to happen to the data inside it.

TL-102 THE PROBLEM

You probably recognise at least one of these.

SYMPTOM
Someone's job is the spreadsheet.
One person keeps the file current and everyone else waits on them. They take leave and the whole thing stops. That isn't their fault. It's just where it ended up.
SYMPTOM
The same thing, typed twice.
Two systems that don't talk, so somebody reconciles them by hand at month end. Ask which one is right and you get a shrug.
SYMPTOM
One file, on one server.
Someone has it open in edit mode. Or the server is down. Either way nobody can find anything until it clears.

REF: TL-102
ANSWERED IN: TL-201 What I build

TL-201 WHAT I BUILD

The kinds of system I build.

PROJECT REGISTERS

One list of every project you've run, with numbers that can't clash.

Numbers issued automatically, on whatever convention you already use
Duplicates blocked by the database, not by someone being careful
A record of who changed what, and when

COMPLIANCE TRACKERS

What's due, what's late, and the paperwork that proves it.

Obligations with an owner and a date against them
Certificates and reports attached to the thing they cover
Late items flagged before an auditor finds them

INTERNAL DASHBOARDS

The numbers your managers keep asking three different people for.

One place to look, pulling from what you already run
Live, not a spreadsheet someone exports at month end
People see what their role allows them to see

SYSTEM INTEGRATIONS

The thing you currently retype out of one system and into another.

One way or both ways, whichever you actually need
On a schedule, or the moment something changes
If it breaks, you hear about it

REF: TL-201
PROVEN IN: TL-301 Built to
BUILD WINDOW: 4 to 6 weeks

TL-202 AI ADVISORY

Your team is already using AI. The question is what they are pasting into it.

Somebody in your office put a client email into a chatbot this week. That is not something to stamp out, it is something to get in front of. I help firms use these tools deliberately, and I write the rules down while we do it.

WHERE IT HELPS: Drafting, summarising, searching your own documents, and the first pass at anything repetitive. The work nobody enjoys and everybody retypes.
WHERE IT DOES NOT: Anything where being confidently wrong is expensive. It does not know your standards, your contracts or your project history unless you hand them over, and handing them over is the decision that needs making carefully.
WHAT NEVER GOES IN: Client information, drawings, tender pricing, anything under an NDA. Unless the tool is one you control and the terms say so in writing.
HOW IT RUNS: Half a day, on site or remote, with the people who actually do the work, using your documents rather than a slide deck. You get a short written note afterwards: what to use it for, what to avoid, and what must never leave the practice. Same format as the security note.

I do this inside a healthcare architecture practice, where a large part of my own job is now automated by it. The rules about what may and may not go into these tools were written because someone had to write them.

In that practice, proposals that used to take three to four weeks now take three to four days. That figure is the practice principal's, not mine.

TL-203 APPROACH

How I work.

01
First I watch you do it.
I sit with the people doing the job, either in your office or over a few calls if that suits you better, because how a process actually runs and how it gets described to me are never the same thing. You come out of it with a written scope saying what is in and what is not, and a fixed price for the build. If you take that document and build it somewhere else, that is a legitimate outcome and I will say so up front.
ONE WEEK
02
Fixed scope, fixed price.
Nothing starts until the scope is agreed in writing. We look at it together twice while I'm building, so there's no surprise waiting for you at the end.
AGREED UP FRONT
03
Live, then looked after.
It is in daily use before the quarter ends. The code, the data and the hosting account are yours from day one. I stay on to look after it if you want me to.
FOUR TO SIX WEEKS

Every engagement is a fixed price, agreed before any work starts. What it costs depends on how much of the process the system has to carry, and that is what the first conversation is for.

Nobody sat down and designed the way your office runs. It accumulated, one workaround at a time.

WHY THIS WORK EXISTS

TL-301 BUILT TO

What everything gets built to.

SECTORS · ARCHITECTURE · ENGINEERING · HEALTHCARE FACILITIES · CONSTRUCTION · REGULATED PROFESSIONAL SERVICES

Capabilities, what each one does, and the evidence behind each
Capability	What it does	Evidence
Registers	Project numbering control, duplicates blocked at the data layer	1,180 records, live
Standards	Document control sitting alongside the projects it governs	BIM standards module, live
Dashboards	Operational reporting, scoped to a person's role	In daily use
Rule checking	Models checked against your standard, failures caught before issue	Revit model checker
Integrations	Two systems kept in step, on a schedule or on change	ACC to backup server sync
Compliance trackers	Obligations with an owner and a date, late items surfaced	Specified, not built

Evidence, not adjectives. Where something is not built yet, the table says so.

HOW IT'S BUILT

Permissions enforced in the database, not just hidden in the interface
An audit trail you can read yourself
You own the code, the data and the hosting account
Migrations tested before they run. No lost rows, no retyping
A written handover, and response times we agree up front

REFERENCE BUILD

Records migrated: 1,180
Years of history: 32
Days to daily use: 9

There is a one-page case study I can send you. Anything deeper, technical detail or a walkthrough, under NDA.

TL-302 SECURITY

These systems end up holding things you can't afford to lose.

Project values. Client details. Staff records. The evidence you would want in front of you if someone audits the practice. I deal with it first, because information security is the other half of my week.

PRINCIPLE
Access control is the floor.
Permissions live in the database. Hiding a button is not security.
Six layers stand between a browser and an enquiry. None of them is the form.
1. 01
  THE BROWSER
  No enquiry is read or written from the browser. The public key the page could use holds no grant on either table.
2. 02
  TABLE GRANTS
  The anonymous and signed-in roles hold nothing on either table. The revocation is explicit, not an oversight that happens to work.
3. 03
  ROW LEVEL SECURITY
  Enabled and forced on both tables. Forced means it binds the table owner too, not only everyone else.
4. 04
  POLICIES
  None. A table with row level security and no policy denies every role it applies to. There is no rule here to get wrong.
5. 05
  COLUMN CONSTRAINTS
  Length, email shape and the fixed lists are constraints on the table, not rules in the form. They hold when the form is bypassed.
6. 06
  THE WRITE PATH
  One server function writes. It checks your input first and tells you plainly if a field is wrong. It rate limits on a keyed hash of your address. And when something breaks on my side it returns one fixed string, because a failure should not describe the machine it happened on.
Two things read these rows: the server, using a key that never reaches a browser, and me, signed in to the database console. That is the entire access list.
This is the enquiry form on this site: one user, no login. A client system has roles, and the schedule is longer. The method is the same one.
PRINCIPLE
Everything is attributable.
You can see who changed what, and when. That record belongs to you, not to me.
WHAT THE RECORD HOLDS
WHAT IS RECORDED
Every create, change and delete: the row, the field, the value before and the value after.
WHO
The named person, not a shared login. One account each, or the record is worth nothing.
WHEN
The server's clock, not the browser's.
WHAT IS NOT RECORDED
Reads. If you need to know who looked at something, say so at the start, because it costs more to build and more to keep.
WHOSE IT IS
The record sits in your database. I can be removed from it without it changing.
PRINCIPLE
You own it.
Your code, your data, your hosting account. If you ever want to walk away from me, you can.
WHAT YOU RECEIVE AT HANDOVER
THE CODE
The repository with its history. Not a zip file at the end.
THE DATA
The database, and a dump of it you can restore without me.
THE ACCOUNTS
Hosting, database, domain and mail, transferred into your name. I keep no access afterwards unless you ask me to.
THE PACK
What it does, how to administer it, where everything lives, who to call, and what is deliberately not included.
THE TEST IT HAS TO PASS
If I disappeared the week after handover, could you keep it running. That is the question the pack exists to answer.
PRINCIPLE
Every build comes with a security note.
Plain English, two pages. What I did, what I deliberately left out, and what is worth checking once a year.
WHAT IS IN THE NOTE
WHAT I DID
The controls that are in place, in the order an attacker would meet them.
WHAT I LEFT OUT
And why. Every system has a boundary. Yours should be a decision rather than an accident.
WHAT TO CHECK IN A YEAR
The handful of things that rot: expiring keys, dormant accounts, a dependency nobody has updated.

REF: TL-302
SEE ALSO: POPIA policy

TL-401 WHO THIS IS FOR

Who I'm a good fit for.

A GOOD FIT

Work I want

You're running a real process in spreadsheets and it's costing you.
Somewhere between 20 and 200 people, with someone who can make a call.
You want to own the system rather than rent it forever.
You can spare a few hours to help me get the scope right.

NOT A FIT

Work I turn down

You need a brochure website. I don't build those.
You're collecting quotes and the cheapest one wins.
Nobody on your side can own the project.
You need it live next week.

TL-402 CONTACT

Tell me what you're running it on.

One sentence about the problem is enough to start. I'll come back to you within a working day.

REF: TL-402
RESPONSE: Within a working day

TL-901 COLOPHON

Two first-party cookies are set by the host and the CDN for routing and bot protection. Neither is mine, neither tracks you, and there are no third-party cookies.

Built by me, in public, to the same rules I build client systems to.

Custom internal software for firms that have outgrown the spreadsheet.

You probably recognise at least one of these.

Someone's job is the spreadsheet.

The same thing, typed twice.

One file, on one server.

The kinds of system I build.

One list of every project you've run, with numbers that can't clash.

What's due, what's late, and the paperwork that proves it.

The numbers your managers keep asking three different people for.

The thing you currently retype out of one system and into another.

Your team is already using AI. The question is what they are pasting into it.

How I work.

First I watch you do it.

Fixed scope, fixed price.

Live, then looked after.

What everything gets built to.

HOW IT'S BUILT

These systems end up holding things you can't afford to lose.

Access control is the floor.

Everything is attributable.

You own it.

Every build comes with a security note.

Who I'm a good fit for.

Work I want

Work I turn down

Tell me what you're running it on.

How this site is built.