Replace spreadsheets with an app: internal business apps
An internal business app is a tool built for your own team, on your own data, to do a job a spreadsheet is straining at: tracking, scheduling, checking or approving. It gives every site the same screen, controlled access and a record of who changed what, which a shared spreadsheet cannot.
- Built from a description
- Runs on your connected data
- Permissions respected
Proof
- 80,000+
- venues on Purple, in 90 countries
- 500 million
- logins across the Purple network a year
- 2 million
- people onboarded every day
- 1,000+
- connectors
Purple runs WiFi and guest data for brands such as McDonald's, JPMorgan, Whitbread, Premier Inn, SoFi Stadium, Pizza Express, Stonegate.
What is an internal business app?
An internal app is a tool your own team uses, built on your own data, for a job such as a schedule, a checklist, an approval or a tracker. It does what a spreadsheet does with structured screens, rules that stop bad entries, roles that control access and a history of every change.
Most internal tools start as a spreadsheet, and that is the right way for them to start. A spreadsheet is the fastest way to find out what you actually need to track. The trouble is not that spreadsheets are bad. It is that they are asked to do jobs that need what they do not have: one agreed shape for the data, rules about what can be entered, control over who can see and change which part, and a record of who did what.
An internal app is the same idea with those four things added. Think of it as the spreadsheet your business has settled on, given structure and guardrails, so that forty sites use it the same way and nobody can overwrite another site's rows by accident.
Automation
Reminders, escalations and updates to other systems happen on their own
History
Who changed what and when, so any figure can be traced
Roles and permissions
Each person sees and changes only what their role allows
Validation
Required fields, allowed values and checks stop bad entries at the door
Screens and forms
One agreed shape for the data, the same at every site
Rows and columns
What the spreadsheet already gives you
How do you know it is time to replace a spreadsheet?
When several people edit it, when decisions depend on it, when it holds personal or financial data, or when one person is the only one who understands it. Three or more of the signs in the checklist below is a strong case for an app.
Signs a spreadsheet has outgrown its job
0 of 9 done
Count the ticks. One or two and the spreadsheet may be fine for another year, with tidier habits. Three or more and the risk is already in the business. It is cheaper to replace the spreadsheet with an app now than after the first error that costs real money.
What are the risks of running operations on spreadsheets?
Silent formula errors, overwritten edits, version drift between copies, no history of changes, no control over who sees what, and dependence on whoever built it. None is dramatic alone. Together they mean the business cannot fully trust the figures it runs on.
Research and case collections on spreadsheet errors, such as those kept by the European Spreadsheet Risks Interest Group, show the same lesson repeatedly: spreadsheet errors are common, they are rarely noticed at the time and they surface when someone makes a decision on the wrong number. The point is not that people are careless. A spreadsheet has no mechanism that stops a mistake, and the larger it grows, the harder a mistake is to see.
| Risk | How it shows up | What an app does about it |
|---|---|---|
| Silent formula errors | A total is wrong and nobody sees why | Calculations live in one place and are tested |
| Overwritten edits | Two people save over each other | Each change is a separate, recorded edit |
| Version drift | Five copies, each slightly different | One shared record, many views |
| No history | Cannot say who changed a figure | Every change has a person and a time |
| All or nothing access | Sharing a sheet shows everything in it | Row-level permissions by site and role |
| Key-person dependency | Only one person understands the workbook | Fields, rules and owners are visible to all |
| Manual transfer | Data is pasted in from other systems | The app reads the connected systems directly |
Which internal apps do multi-site teams build first?
The ones that replace a recurring spreadsheet or email chase with an obvious owner: the checklist, the schedule, the approval, the issue and maintenance log, and a tracker for guests or customers. Choose a job done daily or weekly at every site, where one agreed shape for the data helps at once.
| App | Replaces | Uses data from | Used by | First version contains |
|---|---|---|---|---|
| Checklist app | Paper and shared sheets | Calendar, site list | Frontline staff, site managers | Daily checks, photos, sign-off, overdue chase |
| Schedule app | A schedule spreadsheet per site | Bookings, footfall, availability | Site managers, staff | Shifts, availability, rest-break checks, publish |
| Approvals app | Email chains | Schedule, finance | Managers | Request, route, remind, escalate, record |
| Issue and maintenance log | Calls and emails to facilities | Site list | Staff, facilities | Report with photo, assign, track to closure |
| Guest or customer tracker | A sheet of contacts and notes | Bookings | Front of house, sales | Records, notes, follow-up dates, permissions |
| Onboarding tracker | A checklist in a document | HR, calendar | People team, managers | Tasks per starter, owners, status |
| Stock count app | Count sheets | Till, stock | Site managers | Count, variance, order suggestion |
| Incident log | A folder of forms | Site list | Site managers, head office | Report, severity, actions, review |
What should a schedule app and a checklist app do?
A schedule app must plan against demand and the working-time rules, not only list shifts. A checklist app must prove a check was done, by whom and when, and chase it when it is late. Write the requirements as rules the app enforces, not as screens it shows.
Requirements written as screens ("a page showing the week") produce an app that looks right and does nothing. Requirements written as rules ("flag any shift that leaves under 11 hours' rest") produce an app that protects the business. The two tables below are written as rules.
The schedule rules reflect the UK Working Time Regulations. If you operate elsewhere, hold your own jurisdiction's rules as settings the app checks, so the same app works in every country you run.
| The app must | Because | Rule |
|---|---|---|
| Flag any shift that leaves under 11 hours' rest before the next | Workers are entitled to 11 hours' uninterrupted rest in each 24 | UK Working Time Regulations: daily rest |
| Flag a shift over 6 hours with no break of at least 20 minutes | Workers get a rest break once they work more than 6 hours | UK Working Time Regulations: rest breaks |
| Track hours worked as an average across the reference period | The 48-hour weekly limit is averaged, normally over 17 weeks, unless the worker opts out | UK Working Time Regulations: weekly limit |
| Apply different limits to workers under 18 | Young workers have lower daily and weekly limits | UK Working Time Regulations: young workers |
| Show planned labor cost against forecast sales | A schedule is a cost decision as well as a schedule | Your labor cost percentage target |
| Take availability and time-off requests and show cover | The schedule should start from what people can work | Your policy |
| Route shift swaps to an approver and update the schedule | Swaps agreed by text leave the plan wrong | Your policy |
| The app must | Detail |
|---|---|
| Issue the right checklist at the right time | Per site and per day, with a start and a due time |
| Capture evidence | Photos and notes against a task, with a time and a person |
| Require a named sign-off | The person who completed it and, where needed, a manager |
| Chase and escalate when late | Remind the site, then the area manager after a set time |
| Work in a back room with a poor signal | Save on the device and send when connected |
| Keep a history for audits | Every check, every site, searchable by date |
| Report across the estate | Checks on time by site, region and brand |
How do you set roles and permissions in an internal app?
Give every person a role, and let the role decide what they can see and change, down to the row: a site sees its own site, an area manager sees their region, head office sees the estate. Set this on day one, because retrofitting permissions into an app people already use is painful.
Permissions in a spreadsheet are all or nothing. In an app they work at two levels. The role says what a person can do: view, edit, approve, export, administer. The row-level rule says which rows those actions apply to: their own site, their region, everything. Combined, the same app serves everyone without a separate copy for each.
Design the roles from the people, not the screens. List the real jobs, write what each needs to see and do, and resist adding a role for every exception. Four roles cover most estates.
| Role | Sees | Can change | Can approve | Can administer |
|---|---|---|---|---|
| Site team | Their own site | Their own entries | No | No |
| Site manager | Their own site | Their site's records | Requests from their site | No |
| Area manager | Every site in their region | Records in their region | Above the site limit | No |
| Head office | The whole estate | Any record, with a reason logged | Above the area limit | Roles and settings |
Should you build, buy or keep the spreadsheet?
Buy when an off-the-shelf product fits your process without bending it. Build when your process is yours, the app needs data from several of your systems, or several sites must use it the same way. Keep the spreadsheet only while one or two people use it and the stakes are low.
Build, buy or keep the spreadsheet?
Question 1
Does an off-the-shelf product fit your process without you bending the process to it?
See every path as a list
- Does an off-the-shelf product fit your process without you bending the process to it? Yes, it fits as it is (go to: Buy it.); No, or only after big compromises (go to: Does the job need data from several of your own systems?)
- Does the job need data from several of your own systems? Yes (go to: Build it, from a description, on your connected data.); No (go to: Will more than a handful of people use it every week, or will it hold personal or financial data?)
- Will more than a handful of people use it every week, or will it hold personal or financial data? Yes (go to: Build it, from a description, on your connected data.); No (go to: Keep the spreadsheet for now, with tidier habits.)
- Answer: Buy it. Do not build what you can buy. Check it can read your connected systems and respect your permissions.
- Answer: Build it, from a description, on your connected data. In Purple Build you describe the app and it is created on the data you have connected. Say what to change and it changes.
- Answer: Keep the spreadsheet for now, with tidier habits. Name an owner, lock the formulas and revisit when a second signal from the checklist appears.
Four routes, and when each is right
Keep the spreadsheet
Fits when
- One or two people use it.
- The stakes are low and the data is not personal.
Not when
- Several sites send their own copies.
- Decisions about money or staff depend on it.
Buy off-the-shelf software
Fits when
- The process is standard and the product fits it.
- You do not need your other systems' data inside it.
Not when
- You would reshape your process to suit it.
- It cannot read the data you already hold.
Create it in Purple Build
Fits when
- The process is yours and the data lives in several systems.
- Several sites must use it the same way.
- You want to change it by saying what to change.
Not when
- A product already does exactly this job.
Commission custom code
Fits when
- You are building a product to sell.
- The need is technical and unlike any business process.
Not when
- The need is an ordinary operations job and a queue is the real cost.
For an operations job that reads your own systems and needs to work the same at every site, creating the app from a description on your connected data is faster than a development queue and more fitting than a product built for someone else's process.
Can AI build internal apps for people who are not developers?
Yes. In Purple Build the person who runs the job describes the app and Purple Build creates it on the data they have connected. Fast creation is not the same as safe operation, so every app still needs an owner, validation, a record and a way to change it under control.
The shift is real: the people who understand the job can now describe the tool they need and get it, without waiting for a development queue. That is a large change for operations, facilities, marketing and people teams, who have long had the best ideas for tools and the least ability to build them.
Speed brings its own risk. An app made in an afternoon can end up running the schedule for forty sites. Teams that treat it as a prototype and never put it under control get the same problems as a spreadsheet, with a nicer screen. The difference between an app you can run a business on and one you cannot is the checklist below, and it applies whoever or whatever built it.
| Check | Ask | A good answer |
|---|---|---|
| Data | Which sources does it read, and which fields? | Only the fields the job needs, from named, connected systems |
| Permissions | Who can see and change which rows? | Roles and row-level rules; sources' permissions respected |
| Validation | What stops a wrong entry? | Required fields, allowed values and checks on entry |
| Record | Can you see who changed what and when? | A history of every change, and of every automated action |
| Ownership | Who owns it and who is the backup? | A named person who reviews it on a fixed day |
| Testing | Has it run on real data alongside the old way? | Two weeks of side-by-side with differences explained |
| Change control | How is it changed safely? | Changes are described, reviewed and recorded |
Do frontline apps need to work offline?
Where staff work in cellars, stockrooms, car parks or back-of-house areas with a weak signal, yes. The app should save work on the device and send it when it reconnects, with a clear rule for what happens if two people changed the same record while offline.
Most frontline apps fail not on features but on the cellar. A manager completing a closing check in a room with no signal will not wait to find one. They will do it on paper and enter it later, if at all. An app that cannot cope with a poor connection quietly goes back to paper.
Offline support comes in three levels, and the right one depends on the job. A read-only cache is enough for looking things up. Queue and send works for checklists and logs, where each entry is new. Full offline editing with sync is needed only where several people change the same record, and that is where conflict rules matter.
| Pattern | How it works | Use for | Watch for |
|---|---|---|---|
| Always connected | Needs a signal to work | Office tools, dashboards | Staff revert to paper in dead spots |
| Cache and queue | Saves entries on the device, sends when connected | Checklists, logs, issue reports | Show clearly what has not yet been sent |
| Offline with sync | Edits offline and merges later | Shared records edited by several people | Decide the conflict rule: latest wins, merge by field, or ask |
How do you move from a spreadsheet to an app?
Clean the data, define the fields, import, run the app alongside the sheet for two weeks, train the users, cut over on a quiet day and make the old spreadsheet read-only. Do not try to rebuild every feature of the spreadsheet; rebuild the job it was doing.
Spreadsheet today
The job it does, written down
Then: Describe the app
Describe the app
Screens, roles and rules in plain English
Then: Purple Build creates it
Purple Build creates it
On your connected data
Then: Run alongside
Run alongside
Two weeks, differences explained
Then: Live app; Change it: Describe the app
Live app
Cut over on a quiet day
Then: Archive the sheet
Archive the sheet
Locked, read-only
From spreadsheet to app, in seven steps
Write down the job, not the sheet
State in two sentences what the spreadsheet is for and who reads it. Features you cannot justify by that job are candidates to drop.
Check: Two sentences, agreed by the people who use it.
Clean the data
Remove duplicates, fix inconsistent names and fill gaps. Map each site and person to a permanent ID.
Check: Every row has a site ID and an owner.
Define the fields and the rules
List each field with its type, whether it is required and what values are allowed.
Check: A new entry cannot be saved if it breaks a rule.
Describe the app and review what is created
In Purple Build, describe the screens, roles and rules in plain English. Review what is created with the people who will use it, and say what to change.
Check: A site manager can complete the main task without help.
Run it alongside the spreadsheet for two weeks
Enter everything in both, compare, and explain every difference.
Check: The last week has no unexplained differences.
Train and cut over on a quiet day
A ten-minute demonstration per role is usually enough. Switch on a quiet day and keep someone on hand.
Check: Everyone has used the app once before the cut-over.
Make the old spreadsheet read-only
Keep it as an archive, but stop edits so two versions never exist.
Check: The sheet is locked and labelled as an archive.
What does replacing a spreadsheet save?
The admin hours: copying, chasing, reconciling and fixing. At 40 sites each spending 2 hours a week on a spreadsheet, an app that removes 70 percent of that admin returns 56 hours a week. Use the calculator with your own sites and hours.
Spreadsheet admin calculator
Count the hours each site spends keeping the spreadsheet going, and how much of that an app removes.
- Hours a week on the spreadsheet today
- 80.0 hours
- Hours a week with the app
- 24.0 hours
- Hours returned each week
- 56.0 hours
- Hours returned a year
- 2,688 hours
Worked example. At the defaults, 40 sites each spending 2 hours a week on the spreadsheet use 80.0 hours a week. An app that removes 70 percent of that admin leaves 24.0 hours, so 56.0 hours a week come back, or 2,688 hours over a 48-week year.
How the numbers are built
- Hours per site include copying, chasing, reconciling and fixing, not only editing.
- The share removed depends on how much the app reads from connected systems and enforces rules on entry.
- The calculation counts hours only. Fewer errors and a clear history are extra.
How does Purple Build create internal apps?
You describe the tool your team needs, such as a schedule, a checklist or a tracker, and Purple Build creates it on your connected data, ready for the team to use. Roles and permissions follow your systems. To change it, you say what to change, with no development queue.
Purple Build treats an app as one of four things you make, alongside dashboards, agents and workflows, all on the same connected data. An app built from a description runs on the data you have already connected, so the schedule can read bookings and WiFi footfall, the checklist can read the site list, and the tracker can read the contacts you already hold.
That shared data is the practical advantage. Each app starts with everything the others already know, and the same site IDs, definitions and permissions apply across all of them. You change an app by saying what to change. Production systems stay protected, people see the data they are allowed to see, and every run and action is on record.
Early access goes to the waitlist first, and the systems you name are connected first. We run Purple this way ourselves.
An app needs data to read and write, so start with connecting your business data. Fixed hand-offs between apps are workflows, and what the app captures shows up on a multi-location dashboard.
The options side by side
| Route | Purple Build | Spreadsheet | Off-the-shelf product | Custom development |
|---|---|---|---|---|
| Who creates it | The person who runs the job, from a description | Whoever owns the file | A vendor, for a generic process | Developers, from a specification |
| Fits your process | Yes: described, then changed by asking | Yes, until it outgrows the file | You adapt to it | Yes, once built |
| Reads your other systems | Yes, through 1,000+ connectors | By copy and paste | Only through its own integrations | If the developers build it |
| Roles and row-level permissions | Yes, respecting the sources | No | Usually, per product | If built |
| Change it | Say what to change | Edit the file | Request it from the vendor | Back into the queue |
| WiFi footfall as a source | First class, from Purple | A separate export | Rarely | A custom feed |
Purple Build runs on the same credits as Purple Engage, with a free tier.
Internal business apps
All guides in this pillar
Each guide takes one question in this pillar all the way down, with the diagrams, tables and worked examples to act on it.
Replacing spreadsheets
The risks of shared spreadsheets and how to move a process into an internal app.
Apps teams ask for
What a customer tracker, schedule, checklist, approval or issue app must do.
How apps get built
Internal tools, AI app builders, roles and permissions, offline use and rollout.
Internal business apps
The terms, defined
- Internal app
- A tool built for your own team, on your own data, for a job such as tracking, scheduling, checking or approving.
- Role
- A named set of permissions, such as site manager, that decides what a person can do.
- Row-level permission
- A rule that limits which rows a person can see or change, such as only their own site's.
- Validation
- Rules that stop a wrong or incomplete entry from being saved.
- Audit trail
- A record of who changed what and when.
- Version drift
- The state where several copies of a file are each slightly different.
- Offline sync
- Saving work on a device without a signal and merging it when the device reconnects.
- Conflict rule
- The rule that decides which edit wins when two people changed the same record.
- Change control
- A process for describing, reviewing and recording changes to an app.
- Key-person risk
- The risk that only one person understands a tool the business depends on.
FAQ
Questions operators ask
When should I replace a spreadsheet with an app?
When several people edit it, when decisions about money or staff depend on it, when it holds personal data, or when only one person understands it. Three or more of those signs make a strong case. The cost of an undetected error rises with the stakes, so replace it before the first costly one.
Which internal apps should a multi-site business build first?
Start with jobs done daily or weekly at every site that have an obvious owner: the checklist app, the schedule app, an approvals app and an issue and maintenance log. Each replaces a recurring spreadsheet or email chase, and one agreed shape for the data helps immediately.
Should I build or buy internal software?
Buy when an off-the-shelf product fits your process without you bending it. Build when the process is yours, the app needs data from several of your systems or several sites must use it the same way. Keep the spreadsheet only while one or two people use it and the stakes are low.
Can AI build an internal app without a developer?
Yes. In Purple Build the person who runs the job describes the app and it is created on the data they have connected. Speed does not replace control, so give every app an owner, validation, a record of changes and a safe way to change it, whoever or whatever built it.
What should a staff schedule app do?
Plan against demand and the working-time rules, not only list shifts. In the UK that means flagging under 11 hours' rest, no 20-minute break on shifts over 6 hours and weekly averages above 48 hours, with different limits for under-18s, plus cost against forecast sales, availability and swap approvals.
How do permissions work in an internal app?
Each person has a role that decides what they can do, and a row-level rule that decides which rows it applies to: their site, their region or the estate. In Purple Build the app also respects the permissions of the connected systems, so people see only the data they are allowed to see.
Do frontline apps need to work offline?
Where staff work in cellars, stockrooms or back-of-house areas with a poor signal, yes. The app should save entries on the device and send them when it reconnects. If an app cannot cope with a weak signal, staff quietly go back to paper and the data stops arriving.
How do I migrate from a spreadsheet to an app?
Write down the job the sheet does, clean the data, define the fields and rules, describe and review the app, run it alongside the sheet for two weeks and explain every difference, train and cut over on a quiet day, then make the spreadsheet read-only so two versions never exist.
What does Purple Build cost?
Purple Build runs on the same credits as Purple Engage, so one balance covers both, and there is a free tier to start on. You do not need any other Purple product. Waitlist members get early access first, with the systems they name connected first.
Where to go next
Sources and standards
- GOV.UK: maximum weekly working hours
- GOV.UK: rest breaks at work
- EuSpRIG: spreadsheet risks, horror stories
- ICO: data protection principles, including data minimisation
Reviewed on 9 October 2026.
Run your whole business from one place
Name your systems, tell us your first build, and they are connected first when early access opens. Or talk it through with the Purple team today.
- Join the waitlistLeave your details and you are first in for early access.
- Tell us what to connectTell us which systems you want to connect and what you would build first, and we connect yours first.
- Get early access firstWaitlist members get early access before anyone else, with a free tier to start on.
Early access
Get your systems connected first
Two questions: which systems you run, and what you would build first. That is all it takes.