I set out to build Keystone SG. I ended up building Studiobooks too.

I set out to build an app for Keystone SG, a security business. Along the way, I found myself building a second app to manage the work around it. That became Studiobooks.

The two solve different problems, but they came from the same place: looking closely at what people need to get through a working day, then building the tools to support them.

I'm particularly proud of Keystone. There is a lot to it now, from planning patrols to keeping customers informed. But some of the work I care most about barely appears in a screenshot. It is the care behind who can see information, how sensitive details are stored, and what happens when something goes wrong.

Start with the working day

Keystone SG brings together the office, guards carrying out patrols and customers whose properties are being looked after. Those are three very different views of the same operation.

The office needs to plan the night, allocate people and equipment, review reports and deal with the commercial side. A guard needs a clear next job, the information they are authorised to use, and a straightforward way to record a visit. A customer needs to know what happened at their property and find the relevant report without navigating the office's entire system.

That shaped the build. A report is part of a chain: a visit is scheduled, a guard records it, the office reviews what needs attention, and the customer sees the information intended for them. Making each screen look good matters. Making those handovers work matters more.

Borrow the working idea, then make it fit

One of the first things I wanted to push further was scheduling. I already had something useful in CrewBook, the app we use at Edwards Surfacing: a day view with a pool of workers and a practical way to allocate them to work.

That was a good starting point for Keystone, but a security operation has its own requirements. A guard being free on a calendar does not, on its own, make them the right person for a shift. Availability, licence status, required skills, equipment and coverage all need consideration.

We developed the schedule into an Operations Board, bringing guard allocation, shift rates, equipment and coverage into the planning workflow. The useful idea came from a working business; the detail had to belong to Keystone.

Later, we made the Equipment centre easier to reach and added regular checks, maintenance flags and an issue-and-return workflow. A damaged item should lead to an action, rather than quietly remaining available for the next shift.

Going beyond a digital job sheet

As the build developed, I kept looking for places where it could help the office make a decision, or stop useful knowledge disappearing between visits. These were some of the additions that took it beyond a basic patrol-and-report app.

Better context for the next decision

Growth Radar explores how a prospective site might fit the operation. We added address lookup and a movable map pin, because an address match is not always the entrance a guard actually uses. Its planning estimates still depend on the quality of the inputs.

Change Watch supports comparisons between reference photographs and later inspections, with human confirmation of findings. The point is to help someone notice and investigate a change, then carry a confirmed finding into the site's history.

The work I am proudest of is behind the screen

An app for a security business carries a particular responsibility. Property access information, personal details, photographs and operational records deserve careful handling. A tidy dashboard does not answer the question of who can actually retrieve them.

We worked on several layers together: account verification, permissions, sensitive-field encryption and private attachment access. Each addresses a different part of the problem.

MFA has to protect the work behind the dashboard

For administrators, we built an approval and authenticator flow, with verification checked by the backend before protected operations run. Signing in through a provider and proving an additional factor to the application are distinct things.

I have written separately about the decisions, setup and session checks in “A password shouldn’t be enough to run the whole app.” There is also a step-by-step Base44 Builder guide for readers who want to understand how to approach their own implementation.

Encrypt the sensitive values, and bind them to their home

Keystone's protected fields use AES-256-GCM authenticated encryption. That includes guard personal details and selected sensitive operational fields, such as access notes, staff phone numbers, SIA licence numbers and shift notes.

In plain English, authenticated encryption is designed both to conceal the saved value and to reject it if the encrypted data has been altered. We went further in the newer format: a protected value is also tied to the particular record and field it belongs to.

That last detail matters. An encrypted value copied into another record, or into a different field, should not suddenly become readable there. The implementation checks that binding when it decrypts, and our tests exercise the wrong record, wrong field, wrong key and modified data.

This is selective field encryption, rather than a claim that every database field has received that extra layer. It is also server-side encryption, not end-to-end encryption: an authorised backend operation must be able to read the information to do its job.

Keep documents private too

Sensitive attachments use private storage. Access goes through backend checks before a short-lived signed link is issued. The link expires; it is not intended to be a permanent public address for someone's document.

We also kept sensitive fields out of ordinary CSV exports and masked them in general data views. Protecting a value in its form is only part of the work if a different screen can casually export it.

The awkward cases made the app better

Some of the most valuable fixes came from asking what happens outside the happy path. Can a customer retrieve internal invoice information? Does an issued invoice change when somebody later edits a client's address? Does “Open report” open that patrol's report, or just a general queue?

Those questions led to concrete changes. Customer invoices are returned through a checked backend operation with an explicit set of document fields. Issued invoices retain a snapshot of the company and customer details. Visit-specific links take people to the report they selected.

Even the encryption tests needed scrutiny. One test sometimes changed the encoded text without changing the underlying encrypted bytes. We corrected it to alter the actual bytes, so it reliably tests whether tampering is rejected. A green test is useful only if it tests the thing you think it does.

Recovery received attention too. We built encrypted SharePoint backup packages, including private attachments, and a separate Offline Reader that can open a downloaded recovery set with the key supplied separately. Reading a real recovery set back outside the app was an important check. A complete restore drill remains a separate exercise.

We also worked through the phone experience across all three roles. Clear next actions, visible approvals and readable reports are particularly valuable when someone is trying to do a job rather than explore an app.

Then the build needed its own app

While Keystone was taking shape, another need became clear on my side of the relationship. I needed a proper way to stay connected to the customer, present the proposal, issue the order form and invoices, show the app as it developed, and hand over the finished work.

The app being built was becoming more joined up. I wanted the experience of working with EdwardsApps to feel joined up as well.

That was the beginning of Studiobooks. It became the back office and client portal I needed for my own studio, and I opened it up for other app and software studios to use.

1. Set out the work. Create proposals customers can review and accept, followed by the agreement and order form.
2. Keep the commercial details together. Manage invoices and recurring billing alongside the client relationship.
3. Show the work as it develops. Keep app and demo links accessible, so a conversation can move from describing a feature to trying it.
4. Make handover easy to find. Share final designs and supporting documents, and give customers the finished app links and store links through their portal.

The portal carries the studio's own branding and gives customers a place to return to for their apps, proposals, invoices and paperwork. The practical aim is simple: keep the customer connected to both the build and the business delivering it.

Studiobooks is now available for other studios on the App Store for iPhone and iPad, as well as on the web. It is the same product I built to support my own work.

What stays with me

Keystone started as a custom app for a particular business. Working through it led to better planning, a continuing memory of site issues, more deliberate data protection and a second product for the studio behind the build.

I'm proud of how far it has come. I'm especially proud that we kept asking the less visible questions: who should be able to read this, what happens if the data changes, and how will someone recover the information when they need it?

The best additions came from paying attention to the work — both the customer's work and my own.