About
IndieSoft is a small engineering team with its own products. Everything we say about how software should be built is something we have already had to live with.
Mission and vision
Crafting Digital Excellence through innovative software and scalable engineering.
Build trusted software products that solve real business problems.
How we build
Three commitments that decide most of the smaller arguments before they start.
Dairy360, Print360 and Nexora came before this website did, and that ordering is deliberate. Everything we claim about how software should be built is something we have already had to live with on our own products — including the parts we got wrong and had to pay for later.
A dependency is a commitment to someone else's roadmap. We prefer what the browser already does, then a package we have read, then a package we have heard of — in that order. This site is the argument: its accordion is a <details> element and its anchor navigation is an <a href>.
Empty states, error paths, keyboard order, the 320px width, the screen reader. These are the parts that get cut when a deadline moves, and they are the parts that decide whether software is usable by everyone who has to use it. We budget for them at the start, because they cannot be added at the end.
Engineering principles
No metrics, no logos, no claims about scale. Six principles and what each one costs us.
Product-first mindset
We build our own products, so we live with the decisions we make. That changes what you optimise for — the second year matters more than the first demo.
Maintainable architecture
We optimise for the engineer reading this code in three years, who will not have the context we have today. Boring, obvious and greppable beats clever every time.
Performance
Speed is a design constraint, not a phase at the end. We budget it, measure it on a mid-range phone, and treat a regression as a bug rather than a trade-off.
Accessibility
Keyboard operability, real semantics and legible contrast are requirements we build against, not an audit we survive. If it only works with a mouse, it does not work.
Security
Least privilege, validated input and dependencies we can account for. We prefer the platform to a package, and a package we have read to one we have heard of.
Long-term support
Software is a commitment, not a delivery. We plan for upgrades, handover and the day someone else maintains it — including the day that someone is not us.
Products
Three products, one set of engineering standards. They are why the services exist rather than the other way round.
Future direction
The direction is more products, not more services. Every engagement we take on teaches us something about a domain, and the ones worth keeping become products we own and maintain rather than projects we hand over.
That constrains what we say yes to. Work we would be learning on someone else's budget is work we would rather decline than deliver badly, and we would rather tell you that at the start than discover it together in month three.
Tell us what you are building and what it has to do. We will tell you honestly whether we are the right team for it.