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.

When AI makes you slower - valters.solutions

The honest clock includes prompting, waiting, reviewing and re-prompting - sometimes your hands win.

Most of the writing about AI coding agents is about how much faster they make you. That part is real. I use Claude Code and Codex every day and I would not go back. But there is a quieter truth underneath the hype: reaching for the agent is not free. Every time you do it, you pay a cost - and in a few specific situations, that cost is higher than just doing the thing yourself.

Knowing which situations those are is a skill. It is one of the more valuable ones you can build right now, and almost nobody talks about it.

The costs nobody counts

When people compare "me typing" to "the agent typing," they only count the typing. But the agent has overhead that hides in the gaps.

There is the context switch: you stop holding the problem in your head, you write a prompt, and while it runs your attention drifts. There is the review: whatever it produces, you have to read it, and reading someone else's code carefully is slower than reading your own. There is the re-prompt: when it misses - wrong file, wrong assumption, a subtle off-by-one - you go around again, and now you are two round trips deep on something small.

None of these show up in the demo videos. All of them are real. Once you count them, the math on small tasks changes completely.

The five-character edit

You know the variable name is wrong. You know exactly what it should be. It is five characters and one file.

Typing it takes three seconds. Describing it to an agent, waiting, and reading back the diff takes thirty. The agent did not make you faster here - it inserted a slower process between you and a change you already had fully formed in your head. The prompt-plus-review loop only pays off when the thinking is the hard part. When you already did the thinking, the loop is pure tax.

I catch myself reaching for the agent on these out of habit, the way you might open a new browser tab without deciding to. That habit is the thing to watch.

Debugging something you do not understand yet

This is the one that actually bites.

When you hit a bug in unfamiliar territory, there are two paths. You can let the agent read the stack trace and patch it, or you can build the mental model yourself and then fix it. The agent path feels faster, and for the first bug it is.

But you did not learn anything. So the second bug in that same code, you are just as lost - and now you are lost in code the agent wrote, which you understand even less than if you had written it. You have outsourced not just the fix but the understanding, and understanding is the thing you needed to keep. The moment it actually matters - production is down, the fix has to be right, there is no time to go around the loop three times - you have nothing to stand on.

For anything I will have to own, I read it myself first. I will still use the agent to test a hypothesis or check a corner of the codebase. But the model of what is going wrong has to live in my head, not in the chat log.

The throwaway spike

The opposite case cuts the other way, and it is worth naming because it is easy to get backwards.

When I am writing a spike - a rough script to answer one question, code that gets deleted the moment I have the answer - correctness does not matter. Nobody will maintain it. It will never see real data twice. Here the agent should just write the whole thing and I should barely look at it. Reviewing careful code for a throwaway is wasted effort; the review is the expensive part, and there is nothing worth reviewing.

So the rule is not "review less" or "review more." It is: match the review to what the code is for. Load-bearing code you will own - read every line. Disposable code that answers one question - let it rip.

When you do not know what you want

The worst case is the one that feels most like work.

You are not sure what you are building yet. The shape is fuzzy. So you prompt, get something, realise it is not quite it, prompt again, get something else, and forty minutes later you have generated four versions of a thing you still cannot describe. The agent was happy to produce all of them. It will never tell you to stop and think.

Thrashing an agent in circles is not thinking - it just feels like progress because code keeps appearing. When I do not know what I want, the fastest tool is a blank page and ten quiet minutes, or a rough sketch, or a walk. Decide what the thing is first. Then the agent is excellent at building it.

The judgment is the edge

None of this is anti-AI. I am about as far from that as a person can be - I build custom tools for a living and the agents are why I can do it end to end, alone.

The point is smaller and more useful. A craftsman knows which tool fits which job. A nail gun is faster than a hammer until the one moment it is not, and knowing that moment is what separates someone who owns the tool from someone the tool owns. The agent is the same. Sometimes the fastest tool in the shop is your own hands and your own head.

The skill worth building is not better prompting. It is the judgment to feel, before you type the prompt, whether this is a job for the agent or a job for you - and the discipline to stop reaching when it is the latter. That judgment does not come free either. You build it by paying attention to the times the agent slowed you down, instead of only remembering the times it flew.

That noticing is the whole edge.