Hi, nice to meet you
Meet a small software studio that loves building things: why we chase the feeling of a well-made product, the quiet details behind software that just works, and why we write it all down.
Hi. We’re Nomadware, a small software studio. If there’s one thing to know about us first, it’s this: we love building things.
We love the moment a rough idea becomes something you can actually use, and the slower stretch after it, where that thing quietly gets good. We love technology for what it lets a handful of people make. And we still feel a small, private delight when something we built does exactly what it should for the first time.
The feeling of a well-made thing
You know it the moment you touch it. A button that responds before your finger has left the glass. A page that loads and stays put, with no paragraph shoved down by a late image. A search that finds what you meant rather than what you typed. A tool that does the thing you had in mind, then steps aside.
None of it asks for attention. The better it’s made, the less you think about it. What’s left is a kind of ease, the sense that the product is on your side.
That simplicity is never an accident. Behind an interface that feels effortless, someone tried the clumsy version, didn’t like it, and went back. Someone wondered what a person sees on their very first visit, what happens when the network drops halfway, whether the most common task could lose a step. Those questions rarely make it onto a roadmap. They’re the difference between software people put up with and software people are glad to open.
Chasing it for other people
That feeling is what we’re after whenever we build for someone. Not an impressive diagram, not a long list of features, but the moment a user opens what we made, it simply works, and they never give us a thought.
A product is thousands of small decisions. People rarely notice any one of them, but they feel all of them together, so we spend time where nobody asked us to.
We build with coding agents for the same reason. They carry the long, repetitive parts of the work, which leaves us more time, and a quicker rhythm, for what needs taste and judgment: what to make, what to leave out, how it should feel. The decisions stay with our engineers; the agents add pace.
Why a blog
Every studio says it moves fast and keeps quality. We’d rather show it than claim it. So we’re writing it down as we go: the harness, the guardrails, the bugs, the numbers.
There’s a simpler reason too. Our agents begin each session with no memory of the project, so we already write everything down for them: every rule, every decision and the reason behind it, kept where anyone would look. Our agents get the full story every morning. It seemed only fair that our peers get it too.
That includes the parts that broke. A gate that passed and still let a regression through, a bug our agents couldn’t see, a tool we built and then stopped building. Those are where most of the learning is, and a blog that only shows the wins isn’t much use to someone deciding how to build.
It’s the same instinct behind the activity card on our home page. Its numbers (merged pull requests, agent runs, checks, the issues those checks caught) aren’t written by hand; they’re computed from what our agents actually did, refreshed every few minutes.
These notes are for two kinds of reader:
- Founders and product teams deciding how to build their next product, and whether a team that runs on agents is one they can trust with it.
- Engineers curious how a shop like this holds quality when agents write most of the code.
If you’re carrying an idea for something people will be glad to use, we’d love to hear about it.