How is custom software cheaper than hiring an agency?

AI now does most of the build, so a custom tool typically costs a fraction of what an agency would charge - often up to 20× less. An agency's price pays for a whole team's hours and months of work; with AI, one person can deliver the same tool in a fraction of the time.

How long does it take to build?

Weeks, not months. You get a working prototype on your real data within days, then a production tool tuned until it disappears into the routine - saving hours every week once it's live.

Do I own the software, or is it a subscription?

You own it outright - the code, documentation, and keys, built on a standard, well-documented stack any developer can maintain. No monthly SaaS fees, no vendor lock-in.

What kinds of tools can you build?

Custom internal tools, workflow automation that removes repetitive busywork, tools that turn your documents and data into answers, and honest AI advisory on where AI actually pays off.

Small and medium businesses that have outgrown spreadsheets and off-the-shelf SaaS but don't want the cost or overhead of a full agency. Remote, working with clients worldwide.

Who actually builds it?

Valters Cakss - an AI Solutions Architect with nearly six years leading delivery at Scandiweb, most recently as AI Competence Center Lead. One person, end to end: the person you talk to is the person who builds.

What about changes and maintenance later?

You own the code outright, so there's no lock-in - it's yours to keep. For changes, improvements, or ongoing support, you work directly with me.

Own the architecture, delegate the typing

Decide the data model, the boundaries and the contracts yourself - then let the agent type inside them.

An AI coding agent is the fastest builder I have ever worked with and the worst architect. It will write a working module in the time it takes me to describe one. It will also, if I let it, quietly reshape my data model to make the current task easier, pull in a third dependency that does the same thing as two I already have, and name things after the button it is wiring up instead of the concept underneath. None of it out of malice. It just optimises for the next few lines, not for the system.

So the division of labor writes itself. I own the architecture. The agent owns the typing. That line has held up across every project I have shipped this year, and it is the single most useful thing I know about building software with AI.

What stays firmly human

There is a short list of decisions that shape a system's long-term health, and none of them get delegated:

The data model. How you represent the domain is the thing everything else is built on top of. Get it right and features fall out cheaply. Get it wrong and every feature fights it. This is mine.
Module boundaries. What knows about what. Where the seams are. A system with clean seams can be changed one piece at a time; a system without them turns every change into a negotiation with the whole codebase.
Which dependencies to take on. Every package is a permanent liability - an update treadmill, a security surface, a thing that can be abandoned. Adding one is a decision, not a convenience.
Naming. Names are how the system explains itself six months from now. A name carries an idea. The agent names for the immediate context; I name for the concept.
The UX patterns. How the user moves through the thing. The interaction grammar that should be consistent across every screen, so the tenth screen feels like the first.

Notice what these have in common. They are all decisions that are cheap to make once and expensive to change later. They are the load-bearing choices. That is exactly the category a human keeps.

What the AI does brilliantly

Now the other half, because it is genuinely a lot. Once a decision is made and well scoped, the agent turns it into working code faster than I ever could by hand. Give it a clear data model and it will write the migrations, the types, the queries, the form, and the tests, and they will line up. Give it a boundary and it will respect it. Give it a naming convention and it will follow it everywhere without getting bored.

And it handles volume. The tenth CRUD screen, the fortieth test case, the error handling on every branch - the work that is not hard, just large. This is where AI stopped being a demo and became a tool I actually build on. The typing was never the interesting part of the job. It was just most of the hours.

The trade is good. I do the thinking that is scarce and slow. It does the writing that is abundant and fast.

The failure mode to guard against

Here is where it goes wrong, and it goes wrong quietly.

You do not usually hand an agent one big architectural decision and watch it botch it. What happens instead is a hundred small ones. It needs a place to stash a value, so it adds a column here. It needs two modules to talk, so it reaches across a boundary there. It needs a date formatted, so it pulls in a library. Each choice is locally sensible. Each one saves a minute. And none of them were decided on purpose.

Do that for a few weeks and you look up at a system that has no coherent shape. The data model is a pile of conveniences. The boundaries are gone. There are three date libraries. Nobody chose any of this - it accreted, one autocomplete at a time. It is the software equivalent of a path worn across a lawn: no one decided the path should go there, everyone just took the shortcut, and now there is a path.

That is the real risk with AI, and it is not that the code is bad. Line by line the code is often fine. The risk is architectural drift with no author. A thousand reasonable local decisions summing to an incoherent global one that nobody would have chosen if you had put it in front of them as a decision.

You are the tech lead

The mental model that fixes this is simple. You are the tech lead directing a fast, tireless, literal builder. A good tech lead does not review every line. But they are ruthless about one thing: the moment a choice touches the shape of the system, it comes to them.

So I have a rule I say out loud to myself. The moment I am about to let a decision that affects the shape of the system get made by autocomplete - stop, and make it myself. Not review it after. Make it before. The data model, a new dependency, a boundary being crossed, a name that is going to stick - those never get made by the thing generating the next token. Everything downstream of that decision, the agent can have.

In practice this is a few minutes of deciding, then a lot of watching working code appear. I spend my attention on the choices, not the keystrokes. The agent never has to guess about architecture, because I never leave it to.

Why this is the whole pitch

There is a line I use about how I work: the person you talk to is the person who builds it. That is not a slogan about being a small shop. It is the direct consequence of this split.

One person can hold an entire architecture in their head. The data model, the boundaries, the patterns, the reasons - all of it, coherent, in one mind. What one person historically could not do was also produce the volume of code a real product needs, fast. That is the wall you hit alone, and it is why software usually gets built by teams. But teams pay for the volume with coordination, and coordination is where coherence leaks - each person holds a corner, nobody holds the whole.

The agent removes that wall. I keep the whole architecture in one head, and the typing scales anyway. So you get the thing a big team usually has to trade away: coherence and speed at once. The coherence comes from one person owning every load-bearing decision. The speed comes from not doing the typing.

Architecture is the part that does not get delegated. It is also the part that was always the job. The agent took the typing, which I was happy to give up. It cannot take the deciding, and I would not hand it over if it could.

If you have a tool that grew by accretion and now dreads every change, that is usually drift with no author. An intro call is a good place to figure out what the shape should have been.