About Sillstack
We are a small software studio in Orlando. We take on few engagements at a time, quote a fixed number against a written scope, and the engineer who scoped it is the one who builds it.
That is the whole model. Everything below is the reasoning behind it, including the parts that cost us something.
Why fewer engagements
Large firms run layered delivery because it is the only way to operate hundreds of engagements at once. A partner sells it, a manager plans it, and somebody three levels down writes the code having never spoken to you. It works at that scale, and it costs the client context at every layer.
We run the opposite: a small number of projects, each owned end to end by the people delivering it. You get the contact details of the engineers, and questions are answered by whoever wrote the thing you are asking about. It is also the only honest reason a four-week commitment holds — we are not quietly queueing you behind six other projects.
Roughly sixty per cent of a typical build already exists before we start. That is not a shortcut — it is 12 modules hardened in production across every project we ship.
Why fixed price
Hourly billing means the party doing the estimating benefits from being wrong. That is a structural problem rather than a question of anybody’s integrity, and no amount of goodwill fixes an incentive pointing the wrong way.
Fixed price puts the risk of a bad estimate on us, which is where it belongs, because we are the ones claiming to be able to estimate. The trade is that it only works against a written scope — which is why week one produces a specification and no code, and why a change gets re-quoted in writing before anybody touches it.
Breadth, and why the list holds up
20 practice areas across 12 services and 12 sectors is a lot for a studio this size, and it would be a red flag if each were a separate skill. They are not. Multi-location permissions, offline operation, reconciliation and integration are the same four problems wearing different uniforms, and having solved them properly once is what makes the list plausible rather than padded.
Positions, not values
A value nobody would argue with is not worth printing. These are the ones that cost us something to hold.
- 01
The person who scoped it should build it
Context is most of what makes a decision good. Selling with one team and delivering with another throws that away, and the client pays for the gap in rework.
- 02
A scope in writing beats a conversation
Almost every project that went badly was ambiguous before it was late. Week one exists to make the disagreement happen while it is still cheap.
- 03
Reuse, but maintain what you reuse
Copied code rots because nobody owns it. A maintained platform stays current because every project depends on it. That is the whole difference.
- 04
Boring technology, deliberately
Large hiring pools and long support horizons matter more than elegance. The clever choice is enjoyable for us and expensive for whoever inherits it.
- 05
Say the uncomfortable thing early
That the project is bigger than you hoped, that existing software would do, that we are the wrong firm. It costs us work and it is the only reason the advice is worth anything.
- 06
Leaving should be easy
Your repository, your accounts, current documentation, notice periods written in from the start. A client who stays because exiting is painful is not a reference.
What we have delivered
5 projects, each written up with the problem, the approach, and the part that was genuinely hard to get right.
When you should hire somebody else
Most firms will not write this section. It is the most useful part of the page.
- The work is permanent, core and full-time
- Hire. A permanent engineer accumulates context a contractor structurally cannot, and across three years they are cheaper.
- You need deep regulated-industry expertise
- Some domains take a year to understand properly. If yours is one, you want somebody who already has that year behind them.
- You want an architecture our platform does not support
- A different language, a hosting arrangement we do not run. You would be paying us to learn on your money.
- Existing software already solves it
- Sometimes the answer is a product you could buy this afternoon. We will tell you which one, and it costs us the engagement.
If none of those apply, describe how your business runs today and we will tell you which part of it is worth building software for.
Get in front of an engineer