I worked in other people's companies for years before building my own. Different sizes, different clients, different problems. And one pattern I saw everywhere, in various forms, always the same:
The market sells speed. Nobody sells durability.
Because speed is visible. Durability never is — until the day it is missing.
What "hollow" means in practice
I do not mean something abstract. I mean the things I find every time I take over a site someone else built:
- A breathtaking homepage, and a checkout that breaks. That is, the one point in the journey where the customer has already decided to pay.
- A shop that works perfectly as long as nobody touches it. The first update breaks three things, because nothing was written on the assumption that it would ever change.
- Handover with no documentation at all. Whoever picks it up next — or the author himself in two years — starts from zero.
- Problems that get solved again and again. Temporarily every time, billed every time, never at the root.
None of this shows up in the pitch. All of it shows up in the revenue.
Why it happens
Here I want to be fair, because the easy version — "other people are bad" — is both wrong and boring.
It happens because the pitch sells and the maintenance does not.
A client cannot evaluate what they cannot see. They do not know whether the code underneath is clean, whether it will survive two years, whether someone else could pick it up. They know two things: what it costs and when it will be ready.
So that is exactly where the competition happens. And the one who said "yes, in two weeks" always wins it.
Nobody buys "it will not break". You only value that after you have lived through the opposite.
The decision
I started iRox with no clients.
That sounds reckless, and partly it was. But it was also the only thing that let me avoid building the company around filling a calendar. When you start with ten projects in hand, the calendar makes your decisions for you.
The idea was simple: a small software boutique. Not because "small" is romantic, but because size determines what you can honestly promise.
The name
The name came from iron — and the x from ox. Iron oxide. Rust.
It sounds odd for a company name, until you think about what rust actually is: what happens to iron when you leave it alone.
It does not snap. It decays quietly, from the inside, while the outside still looks solid — until the day you lean on it and it gives.
That is exactly what happens to software nobody looks after. It does not collapse; it oxidises. A dependency left for years without an update. A temporary fix that became permanent. A part nobody dares touch any more, so everyone works around it.
So the name does not say what I sell. It carries the problem I am trying to solve — and it reminds me that iron, however solid, needs someone to keep an eye on it.
What small means in practice
- Few projects at once. One finishes, the next begins.
- The person you talk to is the person writing the code. There is no layer in between mistranslating what you asked for.
- You say no. To work you cannot fit, to work you do not know, to work you can tell from the start will go wrong.
I have seen the opposite from the inside: ten projects in parallel, all at 80%, every client mildly dissatisfied, and a team permanently running without ever delivering anything finished.
That is not growth. It is debt, and at some point it gets paid.
What this choice costs
So this does not sound like I found the trick:
You grow more slowly. You lose work to someone who said "yes" without thinking. Sometimes the client leaves and comes back a year later, having paid twice — and sometimes they never come back, and you never find out what happened.
And the hardest part: good work is invisible. Nobody calls to say "the checkout works beautifully". They only call when it does not.
And so I do not sound like I have solved it
A few days ago I discovered that my own site was telling Google not to read the API that loads the entire content of this blog.
Correct titles. Correct structured data. Correct sitemap. And the crawler seeing empty pages, because one line in robots.txt blocked precisely the request that fetched the text.
I wrote it. I reviewed it. And I missed it.
That does not invalidate anything above — it makes it more accurate. The point is not to make no mistakes. It is to go looking for them, admit them, and fix them at the root, instead of hoping nobody notices.
The difference is not perfection. It is what you do on the day you find the mistake.
What "solutions that last" means
No magic. Boring things, every time:
- Code someone else can read in two years — and that someone else is usually you.
- Documentation that explains the why, not just the what. The code already says the what.
- The problem gets solved at its root, even when the patch takes ten minutes and the right fix takes two days.
- Delivering things that work when nobody is watching.
None of that is impressive in a pitch. All of it shows in year two.
Why I am writing this here
This site is personal. It sells nothing — the commercial work runs through irox.gr.
I am writing it because the decision to start something of my own was not a business decision. It was irritation. I was tired of watching things delivered half-finished and presented as whole.
I do not know whether it is the right model. I know it is the only one that lets me sleep — and that, however small it sounds, is reason enough.
If you are building something and the same thing bothers you, write to me.
Photos: Clark Young, Tyler, Albert Stoynov / Unsplash.