An architect recently described a pattern that is becoming familiar. People in professional practices are using Claude, Codex and other coding assistants to build small tools around their work. A tool might automate part of a BIM workflow, summarise lessons from previous projects or pull key clauses from specifications for a design review. The first version can be genuinely useful, even if its maker would never describe themselves as a software developer.
The problem tends to arrive later. Each extra feature introduces new data, permissions and exceptions. The person who created the tool becomes its support desk. Then another practice asks whether it can use the same thing.
That is the point where an experiment starts to behave like a software product. The idea may still be sound, but the engineering question has changed.
A useful prototype can still be fragile
A tool built for one person benefits from a great deal of hidden knowledge. Its creator knows which BIM export to use, how the practice names project stages, which drawing revisions to ignore and how to recover when a process stops halfway through. They may also be the only user, working on a trusted device with access to every record.
Those assumptions keep an early version small. They also make it difficult to hand over.
Before adding more features, write down the job the tool performs and the conditions it relies on. Which system contains the authoritative project data? What does a successful result look like? Where should a human check the output? What happens to an incomplete run? A short operational description will expose gaps that another prompt is unlikely to solve.
AI generated code needs the same controls as any other production code. It should be stored in version control, reviewed, tested and kept up to date. Dependencies and credentials need deliberate management. The NCSC's guidance for secure AI system development applies across design, development, deployment and operation, including systems assembled from third-party services.
The first useful milestone is therefore a repeatable tool, not a long feature list. Someone other than its maker should be able to use it, understand a failure and recover without editing the code.
External users change the product boundary
Suppose a second architecture practice wants access. The tool now needs to recognise two organisations, their users and the information each user may see. In software terms, each organisation is a tenant.
Logging a user in is only the beginning. Authentication confirms who they are. Authorisation decides what they can do. Tenant isolation makes sure they cannot reach another practice's projects, files or search results, even if a request is malformed or a permission rule has been missed.
AWS describes tenant isolation as a foundation of a multi-tenant system. Its SaaS guidance also recommends carrying both user and tenant context in the system's identity. That context needs to be applied consistently in database queries, file storage, background jobs, logs and support tooling.
There is no universal tenancy model. Some products share infrastructure while isolating every record by tenant. Others use separate databases or storage areas. The right choice depends on the sensitivity of the data, expected scale, client requirements, cost and the team's ability to operate it safely.
The product also needs rules for inviting colleagues, removing access and dealing with consultants who work across practices. Buyers will ask how their data can be exported or deleted. These questions are easier to answer before the data model hardens around one firm's way of working.
Security and operations become product features
For an internal prototype, a failure might mean asking its creator to restart it. A commercial product needs a more dependable response.
Start with a threat model. Identify valuable data, likely misuse and the routes an attacker or an accidental user could take. Protect privileged accounts with multifactor authentication. Keep secrets out of source code, validate inputs and record important changes in an audit trail. Test backups by restoring them. Monitor failed jobs, unusual access and growing costs rather than waiting for a client to report a problem.
If the tool handles names, contact details or other personal information, privacy belongs in the design. The ICO's data protection by design guidance says organisations should consider data protection at the design stage and throughout the lifecycle. That affects what is collected, where it is sent, how long it is retained and who can retrieve it. Specialist advice may be needed for the particular data and use case.
AI services add another supplier boundary. The team should know which material is sent to a model provider, what that provider retains, where processing takes place and how a client can opt out of a feature if required.
Operations also include releases, rollback, incident handling and support ownership. These are part of the service a client experiences, even though they never appear in a product demonstration.
A sensible route from practice tool to product
A better starting point is one narrow workflow that can be tested in another practice without carrying every assumption from the original office.
- Define the product boundary. Choose one valuable workflow, the user responsible for it and the point where a human approves the result.
- Expose the hidden assumptions. Document roles, tenant boundaries, source systems, data retention and common exceptions.
- Test the architecture. Review the generated code, threat model the service and decide which parts need rebuilding before they carry client data.
- Pilot with a second practice. A controlled pilot will show which behaviour was genuinely reusable and which behaviour only fitted the original office.
- Establish ownership. Decide who monitors the service, handles incidents, updates dependencies and supports future changes.
This staged approach protects what was good about the experiment: direct knowledge of a real practice problem. It adds enough structure to discover whether there is a viable product behind it.
ORBN can help when a practice tool needs to become software that other firms can buy and rely on. We can assess an existing prototype, turn the workflow into clear product requirements and design a secure route to production. Where a rebuild is justified, our custom software team can deliver the product with testing, observability and a practical handover. If AI is central to the workflow, we can also define the validation and human review that a dependable AI feature needs.
Photo by Zhouxing Lu on Unsplash. Photo ID: Mb32AJpqd-g.