From Excel to a Self-Sustaining Startup Intelligence Platform
Executive Summary: A startup ecosystem had spent years collecting information about Turkish startups, investors, funding rounds, technoparks, and entrepreneurs in an Excel spreadsheet. The requirement was straightforward: turn that accumulated knowledge into a public website with an admin panel. Within about a year and a half it had payments and three subscription packages, and it is still running more than a decade later.
Context
The founder had already done the hard information-gathering work: startup ecosystem data had been collected manually over time and maintained in an Excel spreadsheet.
The request was to turn that existing knowledge into a real product: a public-facing website backed by an admin panel.
The main constraints were:
- I was the only technical person on the project, responsible for backend, frontend, data modeling, deployment, and infrastructure.
- The existing source of truth was an Excel spreadsheet rather than a structured application database.
- The first version needed to be launched around an entrepreneurship event.
- The original plan allowed roughly two months for the launch.
- The platform needed to represent relationships between startups, investors, funding rounds, technoparks, and entrepreneurs rather than simply displaying rows from the spreadsheet.
The key architectural question was therefore “What underlying data model will allow this information to become a maintainable product?”
Decision
I chose to model the ecosystem as a relational domain rather than reproducing the spreadsheet structure inside the application.
I also tightened the delivery plan: instead of spending the full two months preparing for launch, I aimed to get a usable version live within the first month and use the second month for refinement.
Implementation Details
- Designing the relational data model: I modeled startups, investors, funding rounds, technoparks, entrepreneurs, and their relationships as structured application data.
- Building the application: I built the public-facing application with Ruby on Rails and PostgreSQL.
- Migrating the existing data: I wrote Ruby scripts to parse the existing Excel data and populate the new relational structure.
- Building the admin panel: I created an administrative interface so the founder could maintain and extend the data directly instead of continuing to manage the underlying dataset in Excel.
- Owning the full stack: as the sole technical person, I handled backend, frontend, data modeling, deployment, and infrastructure.
- Adding monetization: Within roughly 1.5 years, I added payment integration and three subscription packages, turning the platform into a revenue-generating service.
The admin panel was particularly important. It transformed the founder’s existing knowledge from a static spreadsheet into something the founder could continuously maintain as part of the product itself.
Consequences
- Positive: The first live version was delivered in approximately one month, leaving the second month for refinement rather than initial implementation.
- Positive: The existing Excel dataset was converted into a structured relational database rather than remaining a manual operational dependency.
- Positive: The founder could manage the platform directly through the admin panel, reducing dependency on both the original spreadsheet and the developer.
- Positive: The product evolved from an information platform into a revenue-generating service through payment integration and three subscription packages.
- Positive: I remained the sole technical owner throughout roughly 1.5 years of development and implemented the product’s features during that period.
- Positive: The platform is still active more than a decade after its initial launch. I do not claim that its current implementation is unchanged from the version I built.
- Negative / Cost: As the sole technical owner, I carried the full implementation responsibility across application development, data migration, and infrastructure.
- Negative / Cost: Designing a proper relational model required more upfront thinking than simply reproducing the spreadsheet structure.
- Negative / Cost: The initial scope had to be deliberately constrained to achieve the one-month launch target.
When to revisit
The architectural decision makes sense when valuable domain knowledge is trapped in manually maintained spreadsheets and needs to become a continuously maintained product.
The important condition is that the spreadsheet should represent a real domain rather than merely being a one-time import. When the underlying information has entities, relationships, history, and ongoing updates, modeling the domain explicitly provides a foundation for search, administration, monetization, and future product capabilities.
In this case, the goal was to turn a founder-maintained dataset into a system that the founder could operate independently.
This case note is an anonymized Architecture Decision Record (ADR) from a real-world engagement.