From spreadsheets to a production platform: the real Disrover case

This post documents a real project in production. It's not theory or opinion: it's the case of a company that transitioned from operating in Excel to a web platform that's now used every day to sell, collect payments, and manage inventory.

The problem that needed solving

Disrover grew. Sales volume increased. Sellers needed to record sales in the field. Administrators needed to reconcile payments, manage inventory, and generate reports. All of this was done in Excel.

Excel works for small operations. But when you have multiple sellers, hundreds of clients, and thousands of monthly transactions, Excel becomes a bottleneck. Errors multiply. Information becomes outdated. There's no real traceability.

The solution wasn't adding more spreadsheets. It was building a platform that completely replaced Excel.

The problem was no longer efficiency: it was control, traceability, and operational risk.

The solution: a web platform

I built Disrover as a complete web platform. Sellers use their phones as mobile point-of-sale. Administrators manage inventory, sales, payments, and reports from any browser.

The platform handles the entire cycle: from product creation to sales recording, payment tracking, inventory management, and cash reconciliation. Everything integrated. Everything traceable.

Technical stack

The stack was chosen to maximize clarity, delivery speed, and maintainability, not to optimize resume or trends.

• Backend: Laravel 12.x, PHP 8.2+ with strict typing, MySQL 8.0+
• Admin Panel: Filament 3.3+ (complete CRUD, widgets, forms)
• Frontend: Laravel Blade, Tailwind CSS, Alpine.js, Livewire
• Infrastructure: Laravel Forge (automatic deploy), DigitalOcean (VPS), Redis (cache and sessions)
• Storage: AWS S3 (logos, avatars, documents)
• Testing: Pest (TDD), PHPUnit, PHPStan Level 5, Laravel Pint
• Documents: DomPDF (invoices, receipts, guides), Laravel Excel (exports)

All technical decisions were validated with real usage. No technology for technology's sake.

Architecture and quality

The project follows Clean Architecture principles and TDD:

• Repository Pattern for data abstraction (new code)
• Service Layer for complex business logic
• Policy-based authorization with granular permissions per role
• Multi-layer validation: UI, backend, models, and policies
• Strict typing in new code (PHP 8.2+ with declare(strict_types=1))
• Testing with Pest: 279 passing tests, high coverage in critical modules
• PHPStan Level 5 for static analysis
• Complete activity logging for audit trail

Legacy code (initial MVP) uses simpler patterns. New code follows stricter standards. This evolution is intentional: solve the problem first, then improve structure.

Execution

Development started in April 2025. The MVP was in use by June 2025, approximately two months later. Since then, the platform has evolved according to real usage requirements.

I didn't build everything at once. I built the essentials first: products, sales, basic payments. Then I added what was really needed: reports, cash reconciliation, goals and commissions.

The goal wasn't 'building a platform', but replacing Excel without stopping daily operations.

This approach allowed validating the solution quickly and adjusting based on real feedback, not assumptions.

Technical decisions

Why no mobile app initially

Sellers use the web platform on their phones. It works well because it's mobile-optimized. A native app could be useful later, but first I needed to validate that the solution worked. A native app is possible for 2026, depending on budget and real need.

Why no microservices

Microservices would add complexity without real benefit for this case. The application is monolithic by design: simpler to maintain, easier to deploy, faster to develop. When complexity justifies it, it can be refactored. But not before.

Why no heavy BI

The platform has basic reports that cover current needs. I didn't build a complex BI system because it's not needed yet. When it's needed, it can be added. Building what's not needed is waste.

Real usage

The platform is in daily use:

• 6 sellers recording sales in the field
• 2 administrators managing inventory, payments, and reports
• 1 sysadmin monitoring infrastructure
• 554 registered clients in the system
• Intensive use Monday to Friday, lighter use on weekends

These numbers aren't projections. They're real usage, measured month by month.

What the platform does

The platform covers the entire operational cycle:

• Product management: categories, multiple prices (normal, wholesale, special, RAPEL), global and per-seller stock control
• Sales: recording with documents (invoices, receipts), automatic folios, real-time stock validation, time and role-based restrictions
• Payments: multiple methods (cash, check, transfer, credit), partial payments, pending balance tracking
• Inventory: stock by seller and branch, atomic transactions with locking, loss registration
• Purchases: supplier management, merchandise reception, supplier payments
• Goals and commissions: individual goals per seller and product, automatic monthly calculation (2% base + variable bonuses), real-time tracking, notification system
• Reports: cash reconciliation, sales analysis, multi-sheet Excel export, professional PDF generation
• Dashboard: 8 widgets with key metrics, period and seller filters, role-based personalization

Results

Excel is no longer the main system. The web platform completely replaced it. Sellers record sales in real time from their phones. Administrators have complete visibility of inventory, payments, and reports. Commissions calculate automatically every month. The operation went from reactive to predictable.

The platform handles specific operational periods (26th of current month to 25th of next), automatically calculates 19% VAT, generates professional PDF documents, and exports data to Excel with corporate formatting.

I didn't build this to demonstrate technology. I built it to solve a real problem. And it works every day.

The support model is clear: bug fixes are included. New scope is billed separately. This keeps the project sustainable and avoids scope creep.

If you're still on spreadsheets and your operation has grown

If your operation still depends on Excel and volume no longer supports it, we can evaluate it with technical and business judgment. Not every case needs custom software, but when Excel becomes a risk, postponing the decision usually costs more.

Disrover is a concrete example of how it's done. You can learn more about the platform at disrover.com. If you're interested in exploring something similar for your operation, you can contact me via WhatsApp.

Visit disrover.comLearn more about the Disrover platform and its main features

Contact for an initial conversationOpen WhatsApp to schedule a discovery call and evaluate if your case would benefit from a similar solution