Replace a Spreadsheet Workflow From Your Previous Field With a Small Web App

The problem with shared spreadsheets outside tech

Almost every job outside tech runs on a shared spreadsheet that people copy, email and break: a clinic's medicine stock list, a school's marks sheet, a site engineer's inspection log, a shop's supplier orders, a lab's sample register. Two people edit different copies. Someone types a date as text and a formula quietly stops counting it. A row gets deleted and nobody knows who did it. Expiry dates are missed because nobody filters the sheet that day.

Career changers and students from other fields know these sheets from the inside. That knowledge is exactly what most CS graduates lack: how a real workflow runs and where its tools hurt.

What already exists and the gap

• Airtable gives spreadsheets a database underneath, with views, forms and permissions, but it is general-purpose and the rules still have to be designed.
• NocoDB is an open source, self-hostable spreadsheet interface over a SQL database.
• Google AppSheet and Glide build apps on top of existing sheets with little code.

These tools are powerful, but none of them knows your field. The gap is a small app whose data model makes that field's common mistakes impossible, with an audit trail, and built by someone who understands the work. For your career, the gap is proof that you can turn domain knowledge into software real people use.

What you build

Pick a workflow you know first-hand, with several people editing, repeated mistakes and numbers someone totals by hand.

• Roles: at least an editor and a viewer; many workflows also need an approver.
• Data model: tables replacing free-form columns, with types, required fields and constraints (a quantity cannot be negative, an expiry date must be after the received date).
• Screens: only the two or three screens people use most, mobile first if they work away from a desk.
• Audit trail: every change recorded with user, time, old value and new value.
• Import and export: bring the old sheet in, get CSV back out.

Do not copy real personal or company data. Recreate the structure with fake records and ask permission before showing anything that resembles a former employer's internal process.

The technically interesting part

The hard part is importing messy real spreadsheets safely. Real sheets have merged cells, dates in three formats, blank rows, notes typed into number columns and duplicates. Build an import that parses, validates every row against the same schema the app uses, shows a preview with row-level errors, and only commits when the user confirms, all in one transaction. Rerunning the same import must not create duplicates.

The second part is the audit trail. Record changes at the data layer (a trigger or a single write path) so no screen can skip it, and show a readable history per record. Show your evaluator a record, its history, and who changed what.

How to evaluate it

• Error prevention: list the mistakes users described, and show each is now blocked or flagged, with a test per rule.
• Import quality: import a realistic messy sheet of a few hundred rows; report rows accepted, rejected with reasons and fixed by the user.
• Task time: time two real users doing their most common task in the sheet and in the app.
• Feedback: a short structured interview with each user after they try it.

Suggested plan

1. Week 1: talk to two users, collect a sample sheet structure, write the problem page.
2. Week 2: data model and validation rules with tests.
3. Weeks 3 to 4: auth, roles, main screens and audit trail.
4. Week 5: CSV import with preview and export.
5. Weeks 6 to 8: deploy with fake data, user sessions, README and write-up.

Path to a product

The first customer is the place you know: your old clinic, school, lab or family business. If it works there, similar organisations have the same sheet. A small monthly fee per organisation, or a one-time setup fee plus hosting, is realistic. The honest alternative is career value: this is the strongest portfolio piece a career changer can have for web, data and QA roles.

Scope warning

Do not build a general spreadsheet or no-code builder. Do not rebuild every column of the original sheet; build the core workflow. Do not import real personal data. A low-code tool is fine for a first prototype, but build the final version in code if you are aiming at a developer role.

Learn what you need on Sefism

• Full-stack roadmap : the order to learn what this app needs.
• Backend cheat sheet : validation, auth and database constraints.
• PostgreSQL Documentation : constraints, triggers and transactions for the audit trail and import.
• The Mom Test : how to interview users without leading them.
• Can I get into tech without a computer science degree? : how projects like this help career changers.
• Learn to code while working a non-tech job : planning a project around a job.

Get help with this idea

Choosing the right spreadsheet is most of the work. Tauseef can help you pick one with enough substance, shape the data model and plan user sessions that make the project convincing. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session