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.

Every business is a system, and reading it is half the build

Any system is the same shape: an input, a transformation, an output - governed by controls and powered by resources.

When I started out, the standout engineers at my company had all done the same MIT course on systems thinking. I took it seriously, and it quietly became the most useful thing I know. The idea is almost embarrassingly simple, but it changed how I look at every problem: anything you are trying to improve is a system. Something goes in, a transformation happens, and something comes out.

Once you can see that shape clearly, building the right software gets much easier - because most software problems are really just systems nobody has drawn.

Input, transformation, output

Every process, no matter how messy it looks from inside, reduces to the same three parts. A support inbox: messages in, triage and answers in the middle, resolved tickets out. Onboarding: a signed contract in, accounts and access set up, a working customer out. Invoicing, payroll, returns, approvals - all the same shape underneath the surface detail.

Naming those three parts plainly is the first move. What actually goes in? What has to come out? And what is the transformation in between really doing? You would be surprised how often a team can describe their tools in detail but stumble on what the system is actually for.

The transformation needs more than the input

Here is the part the diagram makes obvious. The transformation almost never runs on the input alone. It needs two other things.

It needs controls - the rules and triggers that govern it. The policy that decides what counts as done. The threshold that routes one case differently from another. The "only after approval". The schedule or the event that kicks the whole thing off. Controls are not the work; they are what shapes and starts the work.

And it needs resources - what the transformation draws on to actually run. The people who do the judgement parts, the data it reads, the other systems it calls. Get the input right but starve the transformation of a resource it assumes, and the system stalls.

Input, output, transformation, controls, resources. That is the whole model, and it fits on a napkin.

Why I draw this before writing any code

Most software that fails is not badly coded. It automated a system nobody had actually drawn. The spec described screens and buttons, not what goes in, what comes out, and what governs the bit in between.

So before a line of code, I draw your workflow this way. And the gaps show up almost immediately: the input that is never as clean as everyone assumed, the trigger nobody actually owns, the control that lives only in one person's head, the resource the new system would need but does not have. You find those on paper, in an afternoon, instead of in production, a quarter later.

It also tells you what is worth building

The same lens tells you not just how to build, but whether to. A system with a clear input, a clear output, and a slow, repetitive, rules-based transformation in the middle is a perfect thing to automate. A system whose "transformation" is really human judgement, case by case, is not - you would be automating the wrong box, and dressing up a decision as a process. Seeing the parts separately is what keeps you from building the wrong thing well.

The same shape, all the way down

A whole business is a system made of systems. Zoom in and each department, each workflow, each feature is its own input-transformation-output, nested inside a larger one. The output of one is the input of the next.

That is also why one person who thinks this way can move across product, design, and engineering without it feeling like three jobs. They are not switching disciplines. They are reading the same shape at different scales - which is exactly what you need to take a business problem all the way to a working tool.

This is the first thing I do on any project: draw your work as a system, and find where it leaks before anything gets built. If that sounds like the right place to start, start a project.