9 Lessons from Building a Custom Web Platform for a Fast-Growing Startup
During the pandemic, waiting another day for a spreadsheet update was not just inconvenient. It changed how quickly health teams could respond.
That was the challenge facing SKB Group. Public health data was being processed manually through Excel spreadsheets every day, creating delays in reporting at a time when speed mattered more than ever. Patient case counts, clinic hours, and test breakdowns all had to be processed manually before reports and certificates could be produced.
To solve the problem, SKB Group partnered with Virtual Employee to build EXPOPRÜF, a healthcare reporting and medical certificate generation platform designed to replace the team’s manual Excel-based workflow. The platform automated everything from file uploads to report generation and certificate production.
The project was not simply about building software quickly. It was about deciding what needed to be built, what could be ignored, and how to remove bottlenecks without creating new ones.
The result was a platform delivered in 60 days that received a 10 out of 10 client rating. More importantly, it replaced a slow, manual reporting process with a workflow that could generate reports and certificates in minutes rather than hours.
Here is how it was done.
1. Understand the Problem Before Building the Solution
The first step was not choosing a framework or discussing architecture. It was understanding how the existing process actually worked. The team mapped Sercan Kilinc’s workflow step by step to identify where delays occurred, where errors entered the process, and where manual effort was creating unnecessary work.
That exercise defined what success actually meant. The platform needed more than automation. It needed to handle the input variations the team already worked with and generate outputs that matched existing documentation standards.
Projects that skip this phase often end up with software that technically works but does not fit the way people actually work. Users rarely reject software because it lacks features. They reject software that asks them to abandon workflows they already trust.
2. Reducing Risk Matters More Than Following Architecture Trends
Once the workflow was understood, the team separated Excel processing from certificate generation into two services built using Flask, a lightweight Python framework for web applications. The decision was less about following a modern architecture pattern and more about reducing risk.
Changes to certificate logic could happen without affecting data processing, while updates to reporting features were less likely to break document generation. That separation made the platform easier to change and easier to test under tight deadlines.
On a 60-day timeline, reducing uncertainty often matters more than increasing development speed. The safest architecture decision is usually the one that limits how many things can fail at once.
3. Framework Choice Is Really a Decision About What You Don’t Need
The backend ran on Flask, but the lesson was bigger than Flask itself. EXPOPRÜF, the healthcare reporting and medical certificate generation platform, did not need a database, an admin panel, or session management. Adding them would have introduced capabilities the project was never going to use and complexity the team did not need to maintain.
Instead, development effort stayed focused on the actual problem. ReportLab and WeasyPrint handled certificate generation, while Pandas managed data processing and Excel manipulation.
Some projects become slow because they lack technology. Others become slow because they inherit technology they never needed in the first place.
4. Non-Technical Users Decide Whether Software Survives
The people using EXPOPRÜF every day were healthcare administrators, not developers. If the platform required technical knowledge to operate, adoption would have failed regardless of how well the code was written.
The final workflow was reduced to three simple actions: upload two files, fill in a form, and download the results. Behind that simplicity sat validation rules, in-memory processing, and automatic document generation, but users never had to think about any of that complexity. They simply experienced a process that became faster and easier.
Many custom platforms fail because they are designed around system capabilities rather than how people naturally move through a task. EXPOPRÜF was built the other way around, and that is ultimately what made it stick.
5. Security in Healthcare Is an Architecture Decision, Not a Compliance Exercise
Healthcare software operates under a different level of responsibility. Uploaded files were processed entirely in memory and deleted immediately after each request, which meant no patient data remained on the server between sessions. Transfers were encrypted in transit, and every uploaded file was validated against expected formats before processing began.
Get Virtual Employee’s stories in your inbox
Join Medium for free to get updates from this writer.
Research from IBM’s Cost of a Data Breach Report consistently shows that vulnerabilities discovered after launch become significantly more expensive to fix than those addressed during development. In healthcare, the cost extends beyond budgets and timelines. It also affects compliance obligations and patient trust.
Security here was not something added before launch. It was built into the platform from the beginning.
6. Performance Is Most Effective When It’s Planned, Not Patched
Slow report generation would have created delays for the public health teams relying on the data. During the pandemic, delays in reporting meant delays in decision-making, so performance could not be treated as something to improve later.
The platform used efficient data structures to process large Excel files quickly, while caching prevented the system from repeating calculations it had already completed. Regular refactoring, or code cleanup, helped keep the codebase lean and easier to maintain as the project evolved.
Improving performance after launch is usually far more expensive. It often requires regression testing to make sure existing functionality still works and can introduce entirely new problems along the way. Building for speed from the beginning avoided those risks and kept the project on schedule.
7. Constraints Often Produce Better Software
The project operated under three major constraints: a 60-day timeline, healthcare data requirements, and users who could not afford a steep learning curve during a public health crisis.
Those limitations forced the team to prioritize ruthlessly. Features that did not support the core workflow were left out. Complexity that did not improve outcomes was avoided. Decisions became easier because there was less room for distraction.
Constraints are often treated as obstacles in software projects. In practice, they can become one of the best tools for making decisions.
8. Version Control Is Risk Management
Git tracked every change made during development and made every modification reversible. When certificate generation logic was being developed, it happened on a separate branch without affecting the data processing service. Without version control, a failed experiment late in the project could have cost days that simply did not exist.
Version control rarely receives much attention because it only becomes visible when something goes wrong. That is precisely why it matters. Risk management often stays invisible right up until the moment a team suddenly needs it.
9. What Gets Delivered and What Gets Used Are Not the Same Thing
EXPOPRÜF’s perfect client rating reflects something more important than delivery. It reflects adoption. The platform became part of how the team worked rather than another system that was handed over and quietly abandoned.
That outcome came from continuous collaboration throughout development. The build started with Sercan’s workflow, ideas were tested before decisions became permanent, and feedback was incorporated before final delivery.
The technical expertise behind the platform made the solution possible, while the collaboration between SKB Group and the development team made it worth building.
Software that ships but does not get used is one of the most common failures in web development. The best way to avoid that outcome is to treat adoption as a goal from the first conversation rather than an afterthought after launch.
Conclusion
The 60-day timeline is probably the least interesting thing about this project.
What matters more is the sequence of decisions behind it: understanding the workflow before writing code, reducing risk before it becomes expensive, choosing tools that fit the problem rather than following convention, and designing for the people who will actually use the system.
Businesses rarely remember the technology behind successful software. They remember the spreadsheet they no longer update manually, the report that arrives in seconds instead of hours, and the bottleneck that quietly disappeared.
That is usually the clearest sign that a software project succeeded.
Good software adds features. Great software removes problems.
Author: Team Virtual Employee
