Spreadsheets are wonderful until they aren't. Thousands of rows, several people editing at once, formulas that break, no history of who changed what and no safe way to show the data on your website. At some point, your business needs a real database.
I'm Aldrian, an independent developer. I build database-driven websites and web apps, move data from spreadsheets into proper databases and connect existing databases to the web safely.
When you need a database
- Your website shows lists that change often: products, listings, schedules, members, results
- Visitors need to search and filter a lot of records
- Several people update the same data
- You need a history of changes and who made them
- Data from different sources needs to come together
- Spreadsheets are getting slow, messy or risky
- You need reports that combine data in ways a spreadsheet struggles with
What I can build
Database-backed websites
Public pages generated from database records, like catalogs, directories, listings, event calendars or resource libraries. Update a record and every page that shows it updates too. See directory websites.
Admin screens
Secure forms and lists for your team to add, edit and review records, with validation so bad data doesn't get in. See admin panels.
Spreadsheet migrations
Clean, deduplicate and import your spreadsheets into a structured database, with relationships between tables instead of copy-pasted values.
Imports and exports
Regular imports from files or other systems, and exports to CSV or Excel for analysis.
Connections to existing databases
If your business already has a database, like an older system or an internal tool, I can build a secure web layer on top of it, through an API rather than exposing the database directly.
Reports and dashboards
Queries that answer business questions, displayed as tables and charts.
Database design matters
A well-designed database makes everything else easier. I focus on:
- Clear tables and relationships, so data isn't duplicated
- Constraints and validation, so impossible data can't be saved
- Indexes on the fields people search and filter, so queries stay fast as data grows
- Migrations, so every change to the structure is tracked and repeatable
- Naming that makes sense to the next developer
Databases I work with
- SQLite-based databases like Cloudflare D1, which I use for my own website and apps
- PostgreSQL, including through Supabase
- MySQL and MariaDB, including WordPress databases
- Google Sheets or Airtable as simple sources where they're good enough
I choose based on your data size, budget, hosting and who will maintain it.
Security and access
Data is often your most valuable asset. I build with:
- The database never exposed directly to the internet
- Prepared queries to prevent SQL injection
- Roles and permissions checked on the server for every action
- Encryption in transit, and at rest where the platform supports it
- Audit logs for sensitive changes
- Automatic backups, and tested restores
My Jibong Purr-tection security plugin and Ghostly encrypted chat app show how seriously I take data security.
Performance at scale
Websites slow down when databases aren't designed for growth. I look at query patterns, add indexes, avoid repeated queries in loops and cache popular results. For existing slow databases, see server and database optimization. On Artic Flex, a live store with hundreds of pages, performance and data safety were both part of a careful PHP upgrade.
Migrating your data safely
Moving data is where mistakes are most costly. My approach:
- Back up the source data
- Map every field to its new place
- Clean duplicates and inconsistent values
- Write repeatable import scripts
- Compare counts and samples after import
- Run the old and new side by side briefly if needed
Common mistakes
One giant table. Hard to search, hard to keep accurate.
No backups. Or backups nobody has tried to restore.
Exposing the database publicly. A serious security risk.
Building queries from user input. The classic cause of SQL injection.
No migrations. Structure changes made by hand on the live database get lost and cause errors.
Keeping spreadsheets where they help
Moving to a database doesn't mean banning spreadsheets. Spreadsheets are still great for analysis, one-off calculations and sharing snapshots. The difference is that the database becomes the single source of truth, and spreadsheets become exports you can play with freely without breaking anything. Many teams find this gives them the best of both.
Growing without rebuilding
A well-structured database grows with you. New fields, new tables and new features can be added through migrations without starting over. That's the real payoff of doing the design work properly at the beginning.
What it usually costs
It depends on the data volume, number of tables, admin screens and integrations. A focused first version that moves one spreadsheet into a database with an admin screen and public pages is a sensible start. You'll get a fixed quote after we talk.
How we'd work
- Share your spreadsheets or describe your data.
- I design the database and the screens around it.
- You get a quote with timeline and fixed price.
- I build and import your data.
- We test with real records and users.
- We launch, with backups and documentation.
Let's give your data a proper home
Tell me about your data and how you use it. I'll reply with a plan and a fixed quote.
