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.

Should you build it twice? - valters.solutions

One rough build, two roads to the keeper: rebuild from zero with the lessons, or prune down to the best parts. Which is better is the real question.

There is an old line from Fred Brooks, who ran the team that built IBM's operating systems in the 1960s: "plan to throw one away; you will anyhow." It was expensive advice back then - throwing away months of work hurt. With AI writing most of the code, throwing one away costs an afternoon. So the advice went from painful to obvious, and building it twice has become one of the most useful habits I have.

Here is the case for it, and the cases against.

The first build is a probe, not a product

When a problem is well understood - a standard form, an integration you have done ten times - you just build it once, carefully. Building twice would be silly.

But most interesting work is not like that. The requirements are fuzzy, the data is messier than anyone admitted, and the right shape of the thing is something you have to feel rather than specify. For that kind of work, the fastest way to learn is to build the thing badly, on purpose, and look at it running. The first build's job is not to ship. Its job is to answer questions you could not answer on paper.

Why AI changed the math

This habit used to be a luxury. If the rebuild cost you three weeks, you rationalised keeping the mess: "it mostly works, let's just patch it." The sunk cost won, and the prototype quietly became the product.

AI collapsed the cost of the rebuild. When a clean second version is a few hours, not a few weeks, the calculation flips. The value of starting fresh - no dead ends, no scaffolding you outgrew, no decisions you made before you understood the problem - now easily beats the cost. You are no longer trading weeks for tidiness. You are trading an afternoon for a foundation you actually trust.

What the throwaway teaches you

A running prototype tells you things a specification never will:

The real shape of the data - not the clean version in the brief, the actual one with the nulls and the duplicates and the field everyone forgot to mention.
The two features you were sure mattered and nobody touches, and the one you did not think of that turns out to be the whole point.
Where the workflow actually bends - the step people do out of order, the thing they need on their phone, the report they screenshot and paste into an email.

You cannot spec these. You discover them by putting a working thing in front of a real person and watching what happens.

Two roads to the version you keep

So you have a first build that is mostly there - it works, but not really great, and it carries every feature you tried along the way. There are two honest ways to get from here to the version you keep, and "should you build it twice" is really the choice between them.

Road A - rebuild from zero. Deconstruct the prototype into what it taught you: the real requirements, the data shapes, the decisions you'd make differently. Then wipe the code and build again from nothing, carrying only the lessons. Readiness drops to zero for a moment - and then climbs past where the prototype ever was, because nothing in the new build predates your understanding of the problem.

Road B - deconstruct and prune. Keep the code, but work it backwards: decompile the build into its list of features, then delete them in logical sequence - everything nobody used, everything you added "just in case", everything that only exists because of a decision you have since reversed. Don't build anything that isn't needed. What survives is the best parts, which you then tighten into the real tool. Readiness never drops - the build gets smaller and better at the same time.

Which is better? It depends on where the badness lives:

If the badness is in the foundations - wrong data model, wrong boundaries, architecture chosen before you understood anything - prune all you want, the rot stays. Take Road A. Pruning a building on a bad foundation just gives you a tidier building on a bad foundation.
If the foundations are sound and the badness is sprawl - too many features, dead ends still wired in, three ways of doing the same thing - Road A throws away good work for no reason. Take Road B and cut.
When unsure, run the Road B analysis first either way: deconstructing the build back into requirements costs an hour and tells you exactly how much of it deserves to live. If the keep-list is short, you were on Road A all along - the rebuild is small. If the keep-list is most of the app, prune.

With AI, both roads are cheap. That's the new part. The expensive thing is no longer the rebuild or the pruning - it is not choosing, and letting the "mostly there" version quietly become the product.

The discipline almost nobody keeps

Here is the part that makes or breaks it: you have to actually throw it away.

The trap is the prototype that "kinda works." It is good enough to keep limping along, so you patch it instead of replacing it. Six months later that throwaway is load-bearing and it is rotten - built on assumptions you had already disproved by week two.

So make the disposal real. Name it a prototype out loud. Keep it on a branch. Do not let anyone depend on it. And when you understand the problem - which is the moment the first build has done its job - delete it and start the real one clean, carrying only the lessons, none of the scar tissue.

If you know in your heart you will not delete it, then you are not building a probe, you are building the product badly. Don't tell yourself the throwaway story to excuse a sloppy first pass.

How I use it with clients

This is exactly why the first thing I put in front of a client - a working tool on their real data, within days - is deliberately disposable. It is the cheapest way I know to turn "I think I want X" into "actually, what I need is Y." We learn more from one afternoon with a rough version than from a week of meetings about requirements.

Then the second build is the one you keep. And it is better precisely because it is not carrying the weight of everything we learned it should not do.

Building it twice sounds wasteful. It is the opposite. The real waste is shipping the first thing you built - before you understood the problem - and then maintaining it forever.

If you are staring at a tool that "mostly works" and quietly dreading every change to it, that is usually the first build asking to be retired. An intro call is a good place to figure out whether it is worth a clean second pass.