— Approach
How I think about a problem
Whether it's a website, a product or a platform, I ask the same kinds of questions before designing anything. They come from my client discovery, and the principles behind them are the ones my own systems are built on.
- 01The organisation
- 02The people it serves
- 03The experience
- 04The system
- 01
Understand the organisation before the artefact
A website, a product and a platform are all expressions of how an organisation works. I start with the organisation, then the people it serves, then the experience, and only then the technology.
On a website
The business discovery comes before the brand discovery, and both come before anyone discusses pages or features.
In a system
In Infrakinetic, who owns each business record is decided before an engine is built. Ownership first, code second.
Infrakinetic → - 02
Separate what exists from what is planned
Most bad websites and most bad architecture documents blur the line between what works today and what someone intends to build. I keep them apart, deliberately.
On a website
“What is planned, but not available yet?” So future plans are never presented as current capabilities.
In a system
Infrakinetic’s documentation labels every claim as implemented, deployed, runtime-verified or browser-verified. This portfolio holds itself to the same standard.
Infrakinetic → - 03
The user is not always the decision-maker
Who uses something and who has the authority to decide are often different people. Good design serves both, and never confuses one for the other.
On a website
“Who usually makes the final decision?” The site has to convince the buyer and work for the person who uses it.
In a system
Identity and authority are separate. In the Content Operations Platform every request resolves to an actor with explicit workspace permissions; in Infrakinetic, role and tenant come from the database, never from a login token, and menu visibility is never treated as permission.
Content Operations Platform → - 04
Define the negative space
What something must never do is as important as what it should do. Hard lines make every later decision easier.
On a website
“What should you never become?” and “What should visitors absolutely not feel?”
In a system
AI in Infrakinetic can propose, but never posts money, changes employment or approves anything. One engine owns each record and no other may write it. ChiselForge returns nothing rather than a plausible guess.
ChiselForge → - 05
The real competition is the status quo
People rarely choose between you and a rival. They choose between you, doing it manually, or doing nothing at all.
On a website
“What alternatives do people consider instead of you?” Including spreadsheets, WhatsApp and inertia.
In a system
Infrakinetic is designed against spreadsheets, email and disconnected tools, and its Migration Engine exists because the cost of switching is the real blocker.
Infrakinetic → - 06
Model the operation, then the interface
The structure of a system should come from what people actually do every week, not from a template.
On a website
“What does your team repeatedly create or update, who does it, how often, and what must each item contain?” That answer is the content model, and it decides whether a CMS is needed at all.
In a system
The Content Operations Platform treats content as an operation: models, lifecycle, review, release and delivery, not just stored records.
Content Operations Platform → - 07
Keep what works; integrate before replacing
Rebuilding everything is rarely the strongest option. The strongest system keeps what already works and connects to it cleanly.
On a website
“What tools do you already use, and what do you want to keep instead of rebuilding?”
In a system
Infrakinetic migrates from Salesforce, Zoho, HubSpot and Tally through a governed pipeline. The Content Operations Platform keeps provider-specific features behind adapters, so they can be swapped without touching the core.
Content Operations Platform → - 08
Constraints and discoverability are requirements, not afterthoughts
Accessibility, privacy, compliance, deadlines and how search and AI understand you shape the design. They are captured before it starts, not patched in after launch.
On a website
“What should search engines and AI assistants clearly understand about you?” alongside accessibility, privacy, legal and deadline constraints.
In a system
Tenant isolation in Infrakinetic is enforced by the database from day one, and data-protection erasure is designed into payroll. The websites I build ship with structured data, sitemaps and an llms.txt index.
Websites →
In practice
Three short documents, not a long questionnaire
These principles become a 3-part discovery that every engagement starts with. You describe what people need to achieve and what your team has to run. I recommend the structure and the technical approach.