Web, mobile, cloud and AI. From a first release you can put in front of real users, to a platform your team depends on for years. Built by engineers who also build and run a product of their own.
Technologies we work in
What we do
Four groups of work. Most clients start in one and end up in two.
The software your business runs on, built from your requirements rather than bent out of a template: web, mobile, internal tools and the integrations between them.
Getting a product from an idea to something real users can pay for, scoped down to what has to exist first, designed properly, and shipped while the market still cares.
Adding the capability your product does not have yet: AI where it genuinely helps, automation where people are retyping things, commerce where you are selling, and reporting you can trust.
Adding capacity and keeping things standing: engineers who work as part of your team, infrastructure that survives a bad day, and someone who answers when production breaks.
Our own product
Most development companies have only ever handed software over. We also operate a product of our own, which means we have had to live with our own decisions long after the invoice.
A platform schools run their day on: admissions and enquiries, student records, fee collection, daily attendance, results and report cards, and the communication that keeps parents informed without anyone making thirty phone calls.
Why Ironova
The people on your calls are the people writing the code. No account manager, no translation layer, no discovering in month three that the person who understood the requirement has left the project.
Our team spans web, mobile, cloud and data. That means the technology gets chosen for your problem and your maintainers, not because it is the only thing we know.
We do not only hand software over and leave. We operate a product of our own, which means we have had to live with our own decisions through releases, migrations and bad mornings.
If the timeline is not real, or the work is outside what we do well, you will hear it on the first call rather than discover it together in month three. It is cheaper for everyone at this stage.
How a project runs
Forty-five minutes, no deck. You describe the problem; we tell you whether it is something we have done before. If it is not, we say so on the call.
A paid discovery where the problem is unclear, a fixed scope where it is not. Either way you get a document with what is included, what is not, and what we are unsure about. It is yours.
Working software on a URL you can open, every week. Not a status report. You will see the ugly weeks too.
Documentation, environments, deployment and the reasons behind the decisions. We would rather you could leave and chose not to.
Industries
School and institute platforms: admissions, records, fees, attendance, results and the parent communication around them. We build and run our own product in this sector, so we start from experience rather than from a requirements document.
Clinic and diagnostic systems where appointments, records and reports have to be right, auditable, and visible to the right person only. Access control is a feature here, not an afterthought.
Listing portals, site-visit and lead pipelines, broker and channel-partner tooling, and the document trail a transaction leaves behind.
Storefronts, catalogue and inventory systems, order and fulfilment flows, and the integrations into payments, logistics and accounting that make them usable day to day.
Dispatch, tracking and proof-of-delivery software, with mobile apps built for a phone on a bike in patchy coverage rather than a laptop on a desk.
Multi-customer products where one account must never see another account’s data, billing has to be correct, and onboarding a customer cannot mean a developer running a script.
Working together
Priced off a discovery, billed on milestones, changes re-quoted in writing rather than absorbed and resented. Best when the outcome is knowable.
Engineers working as part of your team, in your stand-ups and your tools, with you setting the priorities. Monthly, with a notice period.
A monthly block of hours for something already live. Rolls over once, then expires. We will not bank hours we cannot honour.
Writing
Why a job table in the database you already run beats a message broker for most products, and the delivery guarantee that constrains every handler.
A tenant filter you have to remember is a bug with a delay on it. Here is an isolation model that fails closed, and the detail that decides it.
Why a fee module can ship without a payment gateway, and what matters far more to a school office than a pay-now button on the parent app.
FAQ
A description of the problem is enough to start. You will get a reply from one of the people who would do the work.