# Turn your user's spreadsheet into a shared app

An agent's guide to delivering a shared app from a spreadsheet workflow, with DeepSpace's planned path around human infrastructure signup.

Your user already has a spreadsheet. It tracks equipment, incoming requests,
or projects. Now more people need to use it, updates are hard to follow, and
the user asks you to make it into an app.

They are asking for a better way to do their work. You should be able to
deliver that without asking them to learn database administration or open
accounts on several developer platforms.

**Product preview, October 11, 2026:** DeepSpace's autonomous account and math
verification flow is planned. Current public signup requires human OAuth.
The SDK's data and collaboration features are documented today; the
spreadsheet import and app behavior below are work you implement for the
user, not an automatic spreadsheet-conversion service.

## Keep the workflow recognizable

Begin with what a row represents and what the user does with it. A row might
be a piece of equipment with a location and checkout status. Or it might be a
request with an owner, due date, and next action.

Keep familiar names for those fields. Ask about unclear business meaning,
especially when a formula encodes a rule. The app should preserve the useful
parts of the workflow while making common actions easier.

Decide whether the spreadsheet is a one-time starting point or must remain
connected. These are different projects. A one-time import doesn't imply
automatic synchronization with future spreadsheet edits.

## Build around the data people actually use

Use DeepSpace's [data model](/concepts/data-model) and
[storage guide](/guides/data-storage) to define the records. Implement and
validate the import for the supplied file format. Check dates, empty cells,
duplicates, and relationships before loading the data into the app.

Give the team the views they need: perhaps a searchable list, a detail view,
and a short form to add or update a record. Realtime updates can let people
see changes without passing around another copy of the file.

Decide who can read and change each kind of record. Use the documented
[permissions model](/concepts/permissions) to enforce that access. Hosting an
app at a public URL doesn't require making every record public.

## Keep infrastructure setup with the agent

The planned autonomous flow will let you create the platform account and
deploy the app yourself, within its allowance. Your user can spend their
attention checking that the equipment view or request queue works as expected.
They won't need to choose a hosting provider or provision a database.

This is where an integrated SDK matters: the data model, app interface, and
deployment have one documented workflow. See
[building from your own container](/agents/build-full-stack-apps-from-your-own-container)
for the current tools and the planned account path.

## Finish with a working shared app

Check that imported records match the source, edits persist after reload,
and two users can work with the intended permissions. Test a failed import
or an invalid entry so the user gets a useful error instead of corrupted data.

Then return the URL and a short explanation of how to use it. Explain whether
future spreadsheet changes will be imported, synchronized, or entered in the
app. If the user needs export, implement and verify it as part of the request.

The planned permanent account will let you return later to add a field or
change a view without replacing the app. Resource limits and content
moderation still apply; payments and legal actions require a human.