A Canadian Consulting Firm
Hardening a Lovable build, inside Lovable.
- Client
- A consulting company, Canada
- Industry
- Consulting & advisory services
- Scope
- Security audit, refactoring, UX/UI optimisation, feature development
- Duration
- 3 months
- Environment
- Lovable.dev, retained
The starting point
The client's team had built the tool themselves. Using Lovable.dev, consultants who understood the work, not the technology, assembled an internal platform that turned their delivery methodology into software: structured client assessments, data collection, analysis, and output their consultants could put in front of a client.
The prototype worked. That was the point of it, and it had already proven the concept internally.
What it hadn't been through was the scrutiny that comes before a tool touches real client data. Consulting firms handle other people's confidential information as a condition of the engagement. Before this could become part of how the firm actually worked, someone had to answer the hard questions: who can see what, what's exposed, what happens when something goes wrong.
They brought in WOLKK for three months to make it real.
One condition: stay in Lovable
The client wanted to keep building. Their consultants had learned to prototype in Lovable, and that capability was worth protecting, the alternative was every future change becoming a ticket for a developer.
So the brief wasn't "rebuild this properly." It was: make it secure, make it good, and leave it in a state where our own people can keep working on it.
That shaped everything. We worked inside the Lovable environment rather than exporting the codebase into a conventional development setup, which is more constrained in some respects, and entirely workable when the constraints are understood. Structure the code so the tooling can navigate it, keep patterns consistent, put the sensitive logic where it can't be undone by a careless prompt.
What we did
Phase 1, Audit
We started with the security review before touching anything. The findings followed the shape typical of AI-generated applications: access control implemented in the interface rather than enforced at the data layer, over-permissive database policies, credentials reachable further forward than they should be, and no consistent handling of failure. None of it was carelessness, these are the things a prototype isn't asked to solve, and the person prompting doesn't know to ask for. We delivered a written report separating launch blockers from technical debt from things that were fine as they stood. The client saw exactly what they were dealing with before committing to the rest of the work.
Phase 2, Refactor and harden
Security. Authorisation moved server-side and enforced at the database level. Row-level policies rewritten so a user can only reach their own firm's and their own client's data. Secrets moved out of anywhere the browser could reach. Input validation and sane failure behaviour throughout. Structure. Duplicated logic consolidated, the same calculation had been implemented in several places with several slightly different results. Components broken down and organised so both the client's consultants and Lovable itself could work in the codebase without breaking things elsewhere. Reliability. Proper error handling in place of blank screens. Validation on the data going in, so the analysis coming out could be trusted.
Phase 3, User flow and UI
The prototype worked because the people who built it knew where everything was. That doesn't survive contact with the rest of the firm. We reworked the flow around how a consultant actually moves through an engagement, what they need at each step, what can wait, what should never be more than one click away. Fewer screens, less re-entry of the same information, clearer state at every point. The interface was rebuilt to a consistent design system, so new screens now look like they belong instead of like the week they were made.
Phase 4, New capability
With the foundation solid, the remaining time went into what the client actually wanted next. Ideas that had been shelved during the prototype phase, because the prototype couldn't carry them, went in: deeper analysis, better output for the end client, and workflow improvements that came directly out of watching consultants use the tool. Several of these came from our side rather than the client's brief. Once the team understood the domain, the gaps were visible.
The outcome
After three months the client had a working consulting tool in production use, secure, tested against the way their consultants actually work, and still in the environment their own team knows how to build in.
That last part is the part they value most. WOLKK didn't take the software away from them. Their consultants continue to prototype and extend; we come in for the work that needs engineering judgement.
Why this model works
The instinct with an AI-built prototype is to rebuild it "properly" on a conventional stack. Sometimes that's right. Often it isn't, it throws away working domain logic, costs more than the situation warrants, and takes the tool out of the hands of the people who best understand what it should do.
The alternative is to treat the AI environment as a legitimate place to run software, and to bring engineering discipline into it: real security, real structure, real testing. That's a different job than a rewrite, and in this case it was the right one.
Built something in Lovable that's ready to be taken seriously? Start with an audit. We'll tell you what's solid, what's a risk, and whether you should stay where you are or move.