You had software built. Do you know what you have?
We read the code that is there, whether a developer or an AI wrote it. You get a verdict on security, scalability and transferability, plus honest advice on your next step.
Who wrote your code?
Both routes produce software that works. The risks underneath them are not the same. Pick the one that applies to you.
You pay every month and you cannot check what for
An agency or a freelancer built it. It runs, the invoices keep coming, and the only party who can judge whether that adds up is the party sending them.
You cannot test what you are told
You hear that something is or isn't possible, or that something is very complicated and will take a few months. You hear investments per project and per month. Nobody can validate any of it, so choosing feels like gambling.
Leaving costs more than you think
Tools sit partly in their account and the knowledge about the system sits in their heads. What you think is yours turns out, the moment you want to switch, to keep you locked in after all.
You don't know what good looks like
Code quality, scalability, security, documentation, price at scale and more. You want a good system, but don't know whether what is being built actually holds up. Something built on a rotten foundation eventually has to be redone.
We read what has been built and put next to it what you pay for it. After that you know whether you are in good hands, and what it would take to leave if you ever want to.
You have an MVP whose front end works, but you have no grip on what's behind it
You put it together yourself and now want to build it out further or have your team officially use it. It works right now, but you don't know whether it truly holds up, or whether it will keep working reliably.
You cannot see safety from the outside
Keys left sitting in the code, a database reachable from outside, everyone on the same permissions. Meanwhile the screen simply does what it is supposed to do.
You only feel scaling problems once it's too late
Quality and consistency of the features, the cost of the system, more data, more (active) users, users in another country and more. All things you only feel once it goes wrong and your system stops running properly.
The foundation is rotten
Database structure, system architecture and code quality and frameworks. AI is 'confidently wrong' and sends you the wrong way. That goes fine, until it's too late: your foundation is rotten, and it's faster to rebuild than to fix.
Our developers review the code, flag what needs fixing including priority, and can fix it for you right away.
Is an investor or a buyer coming into view, or do you want to build on this seriously? This is the first thing they look at. You would rather know it yourself, before somebody else finds it.
AI lowers the bar, but makes mistakes
AI makes coding more accessible, so getting a system working on the outside isn't all that hard. You don't see the importance of what's behind it, you only experience it, often once it's too late.
as often, commits with AI code leak passwords and keys.
Source: Cloud Security Alliance and GitGuardianThe number of reported vulnerabilities in AI-generated code rose further in early 2026. Source: Cloud Security Alliance research note
A developer who looks at the code, the project and the plans from A to Z
We don't only check the code, we look at the whole case: from goals and ambitions to project plans and contracts.
- Security
Who can get in, and what is left open?
Security is about more than where your data sits. We look at the whole chain, including:
- Encryption of the database and keys
- Authorisation setup: required login and the right role to view a page
- Logging and data storage at external parties
- Compliance, such as ISO and NIS2
- Scalability
What happens once it grows?
Growth problems aren't some future show that only starts at thousands of users. Build on a rotten foundation, and your tower comes down.
- Code quality: can it be built on further?
- Feature quality: does everything work as it should?
- Database setup: set up efficiently, or waiting to cause problems?
- Technical architecture: in line with your ambition, or a compromise?
- Transferability
Can you still leave if you want to?
The question under the question: are you locked in with your supplier without knowing it?
- Tool overview with an owner per tool, including data
- Documentation of the code, or the lack of it
- Structure of the code: is the foundation sound or not
- Contract specifications on IP, termination and more
- Value for money
Are you getting what you pay for?
Is your supplier delivering what you pay for, or are you paying too much because you don't know what normal is?
- What your monthly amount actually covers
- What stands against what has been invoiced
- What is usual for a system of this size
- Where you get more than you thought
A report you can read yourself, in three parts
The goal is to validate that it holds up, not to force the conclusion that it doesn't.
The findings
Everything we come across in the review, written in plain language, with what each finding means for your business. All the technical findings sit behind it as an annex and reference.
The action steps
A concrete plan in order: what has to happen first, what can wait and what you can simply leave. We can carry it out for you directly, or you have it done externally.
The conclusion
Whether carrying on with your current partner makes sense, and whether what is there can be built on. The hard truth, including when that truth is that it is fine.
A staffing agency that was stuck with its development partner
The owner had had a bad feeling about it for a while. His development partner was only working on the next sale, and every extension came with steep investments and high monthly costs.
Regardless of the conversations, ownership wasn't his: the code was open to view, but all the platforms the system ran on (database, hosting and more) weren't. Buying that out required paying thousands of euros.
We read the code, exposed where the problems sat, and went through the roadmap and contracts. On that basis we drew up a plan for development, migration and centralisation, and he decided straight away to carry on with us and build an affordable, scalable system he owns himself.
Have someone look at it before you build on
You get a report you can read yourself, a technical annex for your developer and honest advice on your next step. Including when that advice is that you are simply fine.
Or go direct:info@stonewell.ai+31 6 10 69 71 50
Frequently asked questions
Is your question missing? Ask it in the conversation.
No. The report is written for the entrepreneur paying the bill, not for a developer. Where it gets technical, it says what that means for your business. The technical detail sits in an annex you can hand to your own developer or to your supplier.
Then that is what it says. The goal of a review is to validate that it holds up, not to force the conclusion that it doesn't. If you are in good hands with your current party, that is the outcome and you have it in writing.
We need read access to the code and to the environment it runs in. Usually you request that from your supplier yourself, because many contracts say you are entitled to it. If you don't get that access, that in itself already answers the question of where you stand.
Not necessarily. There is often something there that works, and that is more than most companies have. The questions are whether it is safe and whether it holds up with more data, more users, users abroad and customers who want uptime commitments. That is exactly what we check.
That is one of the four things we work out. We list who owns the code, the data, the hosting and the domain, what your contract says about terminating and what switching actually costs. Being locked in is almost never absolute, but it is often more expensive than people expect.
Often we can, but we look at it first. We say honestly whether building on is smarter than starting over, and what that difference costs you. You are tied to nothing: the plan is yours, including when you have someone else carry it out.