The part nobody else tells you upfront.
The real question isn't whether we can build it. It's what happens on day 91. Are you stuck? Do you need to hire a developer? What if we disappear? Here is the whole answer, in public, before you ask.
You own it. In plain language, not in a schedule at the back.
On final payment, the intellectual property in your system transfers to you. The code, the database schema, the design, the documentation. All of it, outright.
Not a licence to use it. Not a lease that lapses if you stop paying for support. Not "you own your data and we own the software", which is the line most vendors use and which means you own nothing that matters.
We don't resell it. We don't reuse your specific build for another client. We can't switch it off, and there's no clause that lets us.
Two things we're precise about, because a lawyer will ask. We keep ownership of our own general purpose tooling that pre-dates your project, and you get a perpetual, royalty free, transferable licence to it that survives us ceasing to trade. And your system uses open-source libraries and frameworks that stay under their own licences, which are yours to use for as long as you like.
Nothing we keep can stop your system running, and nothing we keep can stop you leaving. That's the test worth applying to any vendor, and it's the one most of them fail.
What actually changes hands
The GitHub repository, transferred to your organisation. The Cloudflare account, or the project inside your existing one. The database and every backup of it. Environment configuration and the keys to your own integrations. Written documentation of how it's put together.
There is no separate "source code escrow" arrangement, because escrow exists to hold code the vendor keeps, and you already hold yours.
On Australian infrastructure, in your accounts, managed by us.
- Hosting
- Your system runs on Cloudflare, the same network that carries a large share of the world's internet traffic. There is no server to buy, patch, back up or worry about, and no rack in the corner of the office running a machine nobody wants to touch.
- Where the data sits
- Your database sits in Cloudflare's Oceania region, which for our clients means Australian infrastructure, and we disable the settings that would create read copies elsewhere. That's for Australian and New Zealand clients alike.
- If someone asks the question in a supplier audit, or your head contract flows down a sovereignty requirement, the precise answer is worth reading, because data residency and data sovereignty are not the same claim and we won't blur them.
- Where your data lives, stated precisely
- Whose account
- Yours. The Cloudflare account and the GitHub repository are in your business's name, with your billing and your admin access, and we work inside them. That's the opposite of how most arrangements are set up, and it's the reason the exit path below is short.
- Backups
- Point-in-time restore covering the preceding 30 days, so your database can be rolled back to any moment in that window. You don't run it, you don't schedule it, and you don't find out it's been failing for six months when you need it.
- Who manages it day to day
- We do. Updates, monitoring, security patching, uptime. You own the infrastructure and we operate it, so nobody on your team has to become an accidental systems administrator.
An Australian answers, and in almost every case they built your system.
There is no outsourced support desk. There is no reseller in the middle. There is no implementation partner you've never met, who you have to explain your business to from scratch every time something goes wrong.
The people who built your system are the people who support it. They already know what your sub-assemblies are called, why your second site does receiving differently, and which report the owner looks at on a Monday. That context is most of what makes support fast, and it's exactly the thing a ticket queue destroys.
When it's an account question rather than a technical one, it's your account manager who picks up. He knows your business and he's the person you already deal with. He isn't a server administrator, and we're not going to tell you he is.
Raise an issue from within the app, on the screen where the problem is. It arrives with the context attached, priority-ranked, and it goes straight to the people who built it.
Your staff don't need an email address, a portal login or a phone tree. They click the button on the page that's misbehaving.
When something is actually on fire, you call. An Australian picks up, in business hours that run across the same working day on both sides of the Tasman, and it's someone who can open the code rather than someone who can open a ticket.
A problem that stops work gets dealt with as a problem that stops work. Nothing gets parked into next quarter's release because a release process says so.
Small changes in 48 hours, requested from inside the app.
This is the mechanism that stops a custom system going stale, which is what actually kills them.
Small development
A field moved. A column added to a list. A report that needs a different date range. A screen laid out the way the person using it actually works. A new user role. A tweak to a printed document.
Request it from inside your system. Turned around within 48 hours, as part of support, at no extra cost.
Anything bigger
A new module. A second integration. A genuine addition to what the system does. That gets scoped properly with your account manager first, so you know what it involves and what it costs before anything starts.
No work begins on a bigger piece until you've agreed to it in writing. You will never receive an invoice for something you didn't ask for.
Why this matters more than the build
Every system that fails, fails slowly. It fits perfectly on day one, the business changes, requesting a change is expensive and slow, so nobody bothers, and eighteen months later everyone is back in Excel working around the software they paid for.
The 48-hour turnaround exists to break that. When asking is easy, people ask, and the system stays the shape of the business.
Every month. Not to upsell you.
Once a month, someone from our side sits down with someone from yours. The agenda is not our product roadmap. It's what has changed in your business.
A new supplier with different lead times. A second shift. A customer who wants their own portal login. A compliance requirement that landed from a big account. A report the owner has started asking for every Monday that nobody has automated yet.
The point is that the system keeps up with you instead of falling behind. Most of what comes out of these conversations is small development, which means it's done that week.
If you ever want to run it yourself.
A vendor who makes leaving hard has told you exactly how confident they are that you'd want to stay.
There is no migration project, because there is nothing to migrate. The repository is already yours. The hosting account is already yours. The database is already yours and it's an ordinary database, not a proprietary format that only our tooling can read.
What actually happens is administrative:
- You tell us you're taking it in-house or moving to another developer.
- We remove our access and hand over the operational runbook.
- We walk your new developer through the system, properly, on a call.
- We stay available for a handover period so nothing lands on them cold.
We charge for the handover time and nothing else. There is no exit fee, no data-extraction fee, and no clause that makes leaving expensive.
And if we're not here?
Your system keeps running. It isn't hosted by us somewhere you can't reach, it isn't built on anything proprietary to us, and the code is already sitting in your own repository.
Any competent developer can open it and understand it. We designed the arrangement that way on purpose, because a buyer who has to bet the operation on our survival shouldn't be buying from us.
There's a longer answer, with the limits stated as plainly as the strengths: what you'd actually do on the Monday, what it would cost, and how long a system can run with nobody maintaining it.
The old way, and this way.
| Item | The old way | With Praxa |
|---|---|---|
| Build a custom system | $150,000+ | Under $35,000 |
| Time to live | 6 to 12 months | 30 to 60 days |
| Who owns it at the end | Usually not you | You do |
| Per-user fees | Forever, as you grow | None, at any headcount |
| Keeping it running | A developer on staff, or a consultancy on retainer | An Australian team that already built it |
| Small change | Scoped, quoted, scheduled. Weeks. | Requested in the app. 48 hours. |
| New module | A project, a proposal, a fight about price | Scoped with your account manager |
| Support | A ticket, a queue, an offshore team | A help desk inside your system |
You stop renting software that half fits, and start owning software that does.
Ask us the hard question on the call.
Bring the one you'd normally save until after the contract. That's the conversation we'd rather have first.