When does a team spreadsheet need an app?

The office request sheet began with four columns: request, person, date, status. It worked. Then someone added an owner column, a color for urgent requests, and a note at the top that said, “Please tell Megan when you change a status.”

Now Megan checks the sheet every morning, asks who owns the unassigned rows, and sends reminders in chat. The sheet still holds the requests. Megan holds the process.

That is the point where a small app might help. We make Spryloom, which runs team apps built with coding agents, so we have a reason to care about the answer. But replacing a good spreadsheet with an app nobody wants to maintain is a step backward. The test is whether the work around the sheet has become more important than the cells in it.

A list is still a good spreadsheet

Keep the sheet if people mostly add rows, sort them, and occasionally make a chart. A guest list, a one-time inventory, or a short research log does not need a login screen and a database just because an agent can make one.

A sheet is especially useful while you are still learning what to record. Changing a column takes seconds. You do not have to decide yet what the process is.

An app becomes useful when the same decisions happen around each row, over and over. The signs are familiar:

• Someone has to notice a new row. The sheet records it, but an owner still scans for it.
• The next step depends on the current one. A request goes from submitted to assigned to done, and not every person should make every change.
• The reason for a change matters. A color says “blocked,” but the explanation lives in chat.
• People need different views of the same work. A requester wants to know what happened to their request; an owner wants a queue of work assigned to them.
• The reminder is a person. Someone checks due dates and nudges colleagues because the sheet cannot do it for them.

One sign alone may not justify a new tool. If you recognize three and they happen every week, write down the repeated steps. That description is the start of an app.

Describe the job before the screen

It is tempting to hand an agent the spreadsheet and say, “Turn this into an app.” That tells it what the data looks like, but very little about what people do. It may faithfully copy every column and miss the reason you wanted to leave the sheet.

Instead, follow one row from beginning to end. For an office request, ask:

1. Who can submit it, and what information do they know at that point?
2. Who takes responsibility for it, and who is allowed to assign that person?
3. What are the few real states it can be in?
4. Where should questions and updates live?
5. Who needs to be told when something changes?
6. What should happen when it is done?

You can usually answer these in a short conversation with the people who use the sheet. If you cannot, keep using the sheet for another week and watch how they work. The uncertainty is about the process, and software will only make it harder to change casually.

Build one complete path

The first version needs a complete path through the work, not every spreadsheet feature. For the request example, that might be: submit a request, assign an owner, add a comment, change its status, and find it later. Leave dashboards, custom fields and elaborate permissions until someone needs them.

Here is a useful prompt to give a coding agent:

Build a small office request tracker for our team. A signed-in coworker can
submit a request with a title and description, see all requests, and comment.
An assignee or an app admin can change the status from Open to In progress to
Done. Show who owns each request and keep its comments with it. Store requests
and comments in Postgres. Add a CSV export of the requests. Keep access
invite-only. Make the app usable on a phone.

That is a starting brief, not a finished specification. Sit with one coworker and run a real request through it. Can they tell who owns it? Can they see what changed? Does “Done” mean the same thing to both of you? Fix those answers before importing a year of old rows.

Move the data deliberately

The old sheet is often a mix of current work, historical records and accidental formatting. Do not treat every cell as a requirement.

• Keep the source. Make a copy of the sheet before changing anything.
• Choose the active rows. Start with requests people still need to act on; old rows can remain in the sheet as an archive.
• Map columns to meaning. If “owner” sometimes means requester and sometimes assignee, decide which it means before import.
• Test with a few rows. Include a blank owner, a long note and an odd status. Check what the app shows, then import the rest if it is right.
• Name the handover date. Once the app is working, tell the team where new requests go. Two live places for the same work will disagree quickly.

Ask the agent to build an import if you need one. Import behavior belongs to the app you build; publishing it does not automatically migrate a spreadsheet. Keep an export route too, so the team's records are usable if you later choose a different tool.

Give the team a real place to use it

An app on localhost is useful for testing, but coworkers need an address, sign-in and stored data. If you host it yourself, plan for those pieces along with updates and recovery. If you use Spryloom, publish the app from its folder:

npm install -g spryloom
spry login --email you@yourcompany.com
spry publish .

A new Spryloom app is private. Set its access to invited in spryloom.yaml, publish again, and invite each coworker by email. The app gets its own database when it declares one, and you can publish a changed version at the same address. Spryloom checks sign-in before requests reach the app; rules such as “only the assignee can mark this done” still belong in the app itself.

For now, use replaceable data while trying Spryloom. Its beta does not provide self-service database backup or recovery, and rolling back code does not undo changes to records. If those records are critical, keep an independent export and a recovery plan before moving them.

The use cases show more of this kind of workflow. They are examples, not a reason to migrate a sheet that already does its job well.

The decision in one sentence

Keep the spreadsheet while the work is mostly editing a list. Build an app when a person repeatedly has to carry the rules around that list: who owns each item, what happens next, and who needs to know.