What we use it for
We have done websites for a long time and watch every pixel in them. For portals, records and integrations we used to outsource part of the work, and details got lost between the design and the finished code. AI has let us keep design and development closer together in one team and remove part of the routine work. The time saved goes into design and detail.
It helps most where the work is routine: boilerplate, types and schemas, test data, parts of tests, migrations, basic adapters, repeating components or implementation of an already approved design. Those are hours that move nobody forward and still get paid for. We do not count error states among them. They often hold the most important business logic, so we design them ourselves.
Changes go through review and testing according to risk.
Where we do not let it decide
Typography, spacing, button states, how a form behaves on error. A model guesses those from the average of what it has seen, and average is exactly what we want to avoid. So we tune the interface ourselves and against real content, not against placeholder text.
Three lines we hold
- Decisions about the interface stay with a person. The model may propose options, the team picks.
- The data model and permissions we review by hand and cover with tests for each role.
- We stand behind the running system. When something falls over, it does not matter which tool wrote it.
What the result goes through before you see it
This matters more than which tool wrote what. Code from a model and code from a person take the same route:
- Reviewing every change, in depth according to risk. Not for syntax errors, the compiler finds those, but for whether the code does what we meant rather than something similar.
- Tests for what must never happen: a seat sold twice, a role that can see someone else’s data, a form that submits without a required field.
- Checking against real content and real data, not sample text. One long name and one empty list reveal more than ten pretty screens.
- Decisions that cannot be undone, the data model and permissions, are drawn before the first line is written.
A model is fast at what has been done somewhere before. That makes it good at migrations, types, test data or repeating components, and poor where the job is to choose between two sensible options based on how your company works. There it needs somebody who knows that company.
A simple rule for production
What can be verified by a test can be written by AI. What is only recognised by eye or in production we write ourselves. Interface design, the data model and security therefore stay with us; the rest is a question of speed.
We check this on our own products before offering it to a client. Walio we run and keep developing; WCRM our sales team uses every day, and we keep adjusting it based on how it is used. So we know which shortcuts paid off and which we paid for later.
What it means for the client
A shorter path from brief to first version and more room for detail, because mechanical work takes fewer hours. It does not narrow our responsibility: changes go through review and testing according to risk, just as before.
What does not change is the price of thinking. Deciding how the system should work takes as long as before. That is exactly where it shows whether the result holds up.
For you, that means a faster path to a first version you can verify, not automatically a lower price. Scope, security and the result are still decided by the team. When you can handle a project with AI yourself, we cover in the article Why not build your website or app yourself with AI?
