33signals - problems worth solving, solutions worth building

The next evolution

It's not software. It's work systems.

Work keeps reinventing itself. Every leap added power - and quietly added friction.

~~~1900 BCE~~The meeting
The original business technology.
~~1940s~~The computer
Made the impossible instant.
~~1980s~~Software
Every task got a tool.
~~1990s~~The web
Erased distance.
~~2000s~~The smartphone
Put the office in your pocket.
~~2020s~~AI
Gave the machine a mind.
~~Now~~Work systems
The software updates itself from your work.

Here is the losing trade every tool makes you take: you pay to feed it through forms and dropdowns and what comes back is a degraded, context-stripped version of what you already knew - so you book another meeting to recover it. We end that trade. The work updates the system as a by-product of getting done and the insight comes back richer, not thinner.

The problems worth solving

It is the same story in five different industries.

01Fifty thousand tons of stock moving on a WhatsApp thread.
02Four thousand reports and still no live view across nine sites.
03A management pack that takes two people ten days and lands a week after the month it describes.
04A client who says "I didn't know you did that" about a service you have offered for years.
05A pricing rule that changed last year and nobody can remember why.

None of this is a technology problem. It is the cost of running a purpose-driven business on tools that were never built to talk to each other - patched by your best people, who now spend their week on admin instead of the judgment you actually pay them for.

Everyone sees it. Almost nobody fixes it properly, because fixing it has always meant handing your business to someone who does not understand it.

Who this is for. Operating businesses where the build is material and the platform will become the system of record - regulated, multi-site, or running on a book of clients. If a spreadsheet and a licence will do, we will tell you.

The solutions worth building

What changes the moment the friction is gone.

A work system is software that is updated by the work - not by the people doing the work. Your people should recognise their own jobs in it, on day one.

Software you feed

Five logins to update five systems, so nobody does.
The record rots, because keeping it current is a second job.
What comes back is thinner than what went in - context stripped, then re-explained in a meeting.
Work dies in the dead space between the meetings.
You ask AI what to do next - from scratch - after every call.

A system the work feeds

Answer an email, take a call, do the job - and the system updates itself.
The record fills itself from the work you already do.
The insight comes back richer than what went in - and compounds.
The work keeps moving between the meetings.
One place that remembers everything and nudges the gaps.

First, de-risk

The truth out of the spreadsheets, the inboxes and the threads, into one place you can see. Know your position today, not five days after month end.

Then, accelerate

The same data does the second job. More through the same team, more of your client book seen and served. Growth that does not require you to hire your way there.

Then, the asset

An asset on your register carries value in a raise, a sale or a board pack. A stack of licences never will.

Built for here. How approvals are actually given, how stock actually moves, what a regulator here actually asks for. Priced in rands. All processing on SA-region infrastructure. Your data is never used to train AI models. Independent penetration test before live data. Source code and IP transfer to you on acceptance of each release.

How we build

Not vibe coding - engineering, evolved.

If your experience of AI-built software is a demo that dazzled and then fell apart - or a codebase nobody can maintain because nobody quite wrote it - your scepticism is earned.

This is the opposite construction. Every discipline below is the standard engineering canon, unchanged and ours drops nothing from the list. What changes is who executes it and what enforces it: in most teams the standard is held by people being careful; here it is held by the build itself.

Signed specifications before codeTests written before codeEnforced architecture boundariesSix layers of automated testing, mutation-checkedEvery test traced to its requirementSecurity controls to OWASP ASVS Level 2Seven automated release gatesZero-downtime releases with automatic rollbackInfrastructure as codeStandard, open tooling - no lock-inExternal penetration testIndependent audit before acceptance

We write the controls first. Everything else is built to satisfy them.

Before anything is built, we work out what correct means for your business: where the boundaries fall, how a decision must be made, what can never be allowed to happen. That thinking is the bulk of the work and it is done with you.

You are not buying a system with controls attached. You are buying the controls, with a system attached to them.

The machine then implements until green inside those controls, while our senior engineers decide what correct means and verify it. The hundredth module is written from the same standards as the first - which is not true of people at four o'clock on a Friday.

The glass box. See what the system does and why.

Every test carries a traceability tag naming the specification line it proves - and a test without one fails the build.
Seven gates hold every release: Requirements, Engineering, Testing, Data, Security, Operations, Audit. Red has no human override - the only way past it is to fix the code.
An evidence bundle per module, archived and immutable and an independent per-module audit signed at a commit.
Human code review, per module, by an engineer who did not write it.

We welcome the audit, because we are audit-ready.

Month eighteen: who is still holding the standard?

Any team can write clean code in month one. The question a buyer should ask is what the codebase looks like after the tech lead has moved on, two developers have been replaced and a hard deadline has passed through it. In a traditional team the standard is held by review - it bends a little each time and it does not bend back. A standard enforced by the build cannot be waived on a Thursday.

show the working - how we build

How it starts

The First Move.

Small enough to see the end of. Real enough to judge us on.

Stage 1Understand it

One or two working sessions in, you're looking at a working prototype of your business - flows, roles, data - running as software. Usually within days.

You have: a prototype that proves the shape

Stage 2Prove it

Phase zero: end to end on seeded data, your methods and setup, sandboxed integrations. Its job is to surface what breaks and close every assumption before anyone commits to a date or a fee.

You have: the signed blueprint for the production build

Something real, early. Close to finished, not a mockup and not a slide - something your people can use and your technical team can pull apart. We would rather be corrected early than congratulated too late.

Not your calendar. We do the thinking and we come to you only for the judgments that are yours to make. Every phase has a fixed date and hands over something that works on its own.

No commitment beyond phase zero. If it does not earn the build, you stop - and you keep the complete specification, enough for any competent team to continue.

Bring the thing that is broken: info@33signals.com

Problems worth solving. Solutions worth building.