Public sector · Licensing platform
From a two-sentence email to a multi-council licensing platform.
In 2014 a founder sent us two sentences about property licensing and a question: “Can you build it?” Today it is a platform used by landlords, letting agents and local authorities, each with different responsibilities and each council with its own rules. We have specified, designed and managed its delivery from that first email onwards.
- SectorProperty licensing for UK local authorities
- EngagementSpecification, product design and managed delivery
- Duration2014 to date, continuous
- Key constraintSensitive personal data, regulated process, four user groups
1.0
The challenge
The first risk was the one every founder faces. A short brief leaves a lot of room for guesswork, and guesses are expensive to build.
The second risk grew with the product. A property licence is more than a form. Who owns the property, who manages it, which certificates are in place and who is entitled to apply all change what happens next. Each council scheme adds its own requirements. Applicants need to know exactly what to provide, agents manage many properties alongside colleagues, the client’s team reviews what comes in, and council officers need to see progress and the records behind each decision.
Going straight to build would have meant screens designed around guesses: who can submit, who can change information, what triggers the next step. Each wrong guess would surface later, in the application journey, the admin workload and the messages users receive, all at once.
Then there is the data. A licensing application carries identity documents, proof of ownership, safety certificates and personal details about landlords and the people acting for them. Councils rely on that record when they make decisions. Getting access wrong, or holding data no one needs, isn’t a bug to fix later. It is a breach of trust with every user group at once.
2.0
What we did
Understand
Before anything was built, we turned that first email into 75 pages of rules and specification. That has since grown to thousands of pages of documentation and working prototypes. For every change, we still map what each participant needs to do and which rules govern it. Open questions and dependencies are settled before the relevant development starts, rather than discovered during it.
Specify
Functional specifications cover the user journeys and everything behind them: permissions, conditions, workflow states and communications. They give the client and the development specialists one shared account of how the service should behave, and a fixed basis for scoping and estimating each change.
Much of the value is in the distinctions. The same piece of evidence can need different handling depending on when it arrives and who provides it. The person filling in an application isn’t always the person entitled to make it. Treating those cases as one would have been simpler to build, and would have created the wrong tasks for reviewers and the wrong messages for applicants. We defined each case separately and documented the decision before it reached development.
Prototype
Agreed rules become screen requirements and task sequences, with instructions and feedback written alongside the process so users know what’s needed and what happens next. Where a workflow is new, we prototype it first so the client can test it before committing to build.
Build
We brief specialists from our network against the specification, resolve questions with the client and review what’s delivered against the same documents. The client has had one point of accountability for twelve years, and because the specification is the reference, the product has never depended on any one development team.
Security and data protection, by design
Security is written into the specification, not checked at the end. For every journey, the specification sets out what personal data is collected and why, who can see it, who can change it and what is recorded when they do. Permissions are defined role by role, including what an agent can do for a landlord and what council officers and support staff can access. Identity checks are specified as part of the journey, including how they work for users with accessibility needs.
The specification is written to UK GDPR, with data protection input given before features are built. The platform is penetration tested by a CREST-certified partner we manage, with findings specified and fixed through the same process as any other change. All of our work is delivered under our ISO 27001 certification.
What we produced
- Functional specifications defining business rules and system behaviour
- Workflow definitions covering stages, decisions and exceptions
- Role and permission rules setting out who can act, and on whose behalf
- Working prototypes for new workflows
- Data and access rules for each journey: what is collected, who can see it and what is logged
- Screen requirements and communication rules linking user tasks to admin actions
3.0
The outcome
Licensing for a growing number of council schemes now runs through one service, with applications, evidence and payments in one place. New schemes join every year.
Agents work across all their properties. Council officers can see applications in progress, not just completed ones, along with the records behind them.
The service continues after the licence is granted. Licence holders keep certificates up to date and get reminders before they expire, and councils can monitor the evidence held against each property.
Because the rules have been written down as the product grew, each new requirement is assessed against a documented baseline rather than worked out again from the code.
Square Owl are the kind of partner you build a business with. The team care about our success as much as we do. They bring ideas, challenge us and tackle the difficult problems alongside us. We trust them with the big decisions as well as the detail, and we can always pick up the phone and speak openly. We want them alongside us for years to come.
4.0
What happened next
Twelve years on, the work hasn’t stopped.
The platform evolves in structured cycles: each new requirement is a defined piece of work, with the affected rules, journeys and dependencies documented, the scope agreed, the build briefed and the result reviewed against the specification. Operational feedback sets the agenda, and every change starts from what has already been decided and documented.
Start here
Start with a conversation, not a commitment.
A structured call about where you are and the right next step.