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.

Context is the real product - valters.solutions

Same model, same prompt - the context stack is what separates a lost agent from a great one.

Give the same coding agent the same task twice. The first time, drop it into a cold repo with a one-line prompt. The second time, hand it your house rules, a couple of worked examples, and the reasons behind the decisions already baked into the codebase. You get two completely different engineers. The first guesses and writes generic code that technically runs. The second behaves like a senior who has been on your team for a year.

The task did not change. The model did not change. The context did.

The prompt is overrated

There is a whole cottage industry around prompt wording - the magic phrasing, the role-play preamble, the "you are a 10x engineer" incantations. Most of it is noise. Once your prompt is clear about what you want, squeezing it harder gives you almost nothing.

Context is where the leverage is. A prompt tells the agent what to do right now. Context tells it how things are done here, what has already been tried, and what not to touch. That second category is where all the value hides, because it is exactly what a good human colleague carries around in their head and a fresh agent does not.

An agent with no context is not stupid. It is new. It has never seen your codebase, does not know you settled on TanStack Query over Redux, does not know that the last person who introduced a competing date library caused a week of bugs. So it does the reasonable thing for a stranger: it makes something generic. Generic is the tax you pay for missing context.

What context actually is

When I say context I do not mean a longer prompt. I mean a set of durable artifacts the agent reads every time:

Written house rules. A file the agent loads on every task - stack, conventions, naming, the libraries you use and the ones you have banned. In Claude Code this is a CLAUDE.md. It is the difference between "write a component" and "write a component the way we write components."
Docs. Not exhaustive documentation. The load-bearing stuff: how auth flows, what the data model means, where the bodies are buried.
Worked examples. One real, finished feature the agent can copy the shape of. Show it the pattern once and it will match it. This is worth more than three paragraphs describing the pattern in prose.
The conventions, made explicit. Path aliases, error handling, how you surface user feedback. Things a teammate absorbs by osmosis and an agent has to be told.
The why behind past decisions. The most underrated one by a distance.

Why decisions matter more than code

Code tells an agent what the system does. It does not tell it what you already ruled out and why. Without that, the agent will happily re-litigate settled questions - swap your state library, "simplify" the thing you made complex on purpose, reintroduce the dependency you spent a day removing.

So I keep a running log of decisions. One line each: what we chose, and the reason. "Chose server-side filtering over client-side because the catalog will outgrow the payload." Now the agent knows the boundary and the reasoning. It stops fighting choices I already made, and when a decision genuinely should be revisited, it can argue against the actual reason instead of stumbling into it blind.

This is the part people skip, and it is the part that turns an agent from a fast typist into something that respects the grain of the codebase.

Context compounds, prompts evaporate

Here is the reason this matters more than any prompt trick: context is an investment that pays out over the whole life of the project.

A prompt is spent the moment you send it. Gone. The next task starts from zero. Context is the opposite. You write the house rule once and every future task inherits it. You capture the decision once and the agent stops making that mistake forever. You add the worked example once and everything built afterward matches it.

Which means the agent gets more useful as the project ages, not less. Early on you are teaching it constantly. A few months in, most of what it needs is already written down, and new work slots into a shape that is already coherent. The compounding is real and it runs in your favor.

That reframes what a prompt even is. The prompt is throwaway. The context is the asset. So I treat it like one: I maintain the house-rules file the way I maintain code, I update the decision log when something changes, I add an example when a new pattern earns its place. It is a first-class artifact, versioned in the repo, not a scratch note.

Why this fits a one-person shop

I build custom tools for small businesses end to end, alone. No standup, no onboarding docs for a team of eight, no one to keep in sync. That sounds like a limitation. For working with agents it is an advantage.

The entire context of a project lives in one head and one repo. When I write it down for the agent, I am not translating across five people's mental models - I am externalizing my own, cleanly, in one place. The house rules match how I actually work because I wrote them and I am the only one following them. Nothing drifts out of sync because there is no one to drift from.

So the agent inherits a coherent picture, and I get to move fast without a coordination tax. A solo specialist plus well-kept context behaves less like one person with a tool and more like a small, unusually aligned team.

Stop polishing prompts. Start building context. That is where the good work comes from.