How I Built a Client Management System in One Week to Replace HubSpot
Saved $3,800/year • Running 10+ months maintenance-free • Managing 8+ client accounts
The Challenge
Two weeks before I had to return to school, my company was paying $3,800/year for HubSpot CRM (with only one user. Scaling to two staff would cost $7,600/year). For a small digital agency, this was unsustainable.
The problem I'd experienced firsthand: Working on client projects meant constantly asking, "Where's the contract?" "What did we agree on?" "Where are the assets?" Critical client data was scattered across emails, folders, and conversations.
The ask:Build a replacement that solves the data-sharing problem and eliminates the subscription cost.
The timeline: One week.
The Stakes:
- Solo project (design + development)
- Hard deadline (school resumption)
- Had to design entire UI from scratch
- Team needed to operate it without me
- Zero tolerance for data loss
What I Built
A complete client management system with:
Core Features:
- Client/contact management (company info, contacts, relationships)
- Communication tracking (emails, calls, meetings logged in one place)
- Task & workflow management (project timelines, deadlines, assignments)
- Invoice management (creation, tracking, payment status)
- Document management (contracts, assets, deliverables uploaded and organized)
- Centralized data access (solved the "where is it?" problem)
Technical Stack:
- Backend: Python/Bottle + MySQL
- Frontend: TailwindCSSVanilla JavaScript (ES6 modules)
- Design: Created all UI/UX from scratch (wireframes to final interface)
- Deployment: cPanel production environment
Why I Made These Choices
Vanilla JavaScript Over React
Requirements:
- Fast loading (team would access constantly)
- Simple maintenance (I wouldn't be there)
- Lightweight (no need for complex state management)
Decision: Vanilla JS with ES6 modules
Results:
- 85% smaller bundle than React alternative
- Sub-second load times
- Easy for team to understand and modify if needed
- 40% faster than framework-based prototypes
Python/Bottle Backend
Why not Django or Flask?
- Bottle: ~500 lines for routing + database
- Django: Would need 2000+ lines for same functionality
- Flask: Middle ground, but Bottle was sufficient
Requirements met:
- Fast development (time-constrained)
- MySQL integration (native support)
- REST API (simple routing)
- Team could read the code (explicit > magic)
UI/UX Design Philosophy
Designed for daily use, not first impressions:
- Minimal clicks to common actions
- Clear visual hierarchy (critical info stands out)
- Fast navigation (keyboard shortcuts built in)
- Mobile-responsive (team worked from phones)
- Consistent patterns (once you learn one section, you know them all)
Design Process:
- Sketched workflows on paper
- Built HTML mockups
- Refined with team feedback
- Final UI polish
The Results
Immediate Impact (1 week):
- Eliminated $3,800/year subscription (avoided $38,000 over 10 years)
- All 8+ client accounts migrated
- Team trained and operational
- Zero downtime during deployment
- Solved data-sharing problem (centralized access)
Long-term Impact (10+ Months Later):
- Still running in production without me
- No maintenance required (zero bugs reported)
- Team operates independently (no developer needed)
- System has handled 8+ client accounts
- No feature requests or complaints (designed right the first time)
Business Value
- Cost savings: $3,800/year eliminated
- ROI: System paid for itself in saved subscription fees
- Scalability: Can add unlimited users (no per-seat pricing)
- Data ownership: Full control over client information
- Team efficiency: No more "where is that file?" conversations
What I Learned
1. Constraints Breed Better Products
Before: I would spend weeks 'perfecting" features users didn't need
After: 1-week deadline forced me to ask "what's actually necessary?"
Result: Built only essential features. Team uses 100% of what I built (no bloat).
2. Design for Daily Use, Not First Impressions
Mistake I avoided: I would spend weeks 'perfecting" features users didn't need
Approach:
- Fast loading > fancy animations
- Clear labels > clever UX
- Keyboard shortcuts > mouse-only interface
- Consistent patterns > unique experiences per section
Outcome: Team adopted it immediately (no resistance to change).
3. Build Systems That Work Without You
Critical decision:Comprehensive documentation + simple architecture
Why it mattered::
- I left for school 2 days after launch
- Team needed to operate independently
- No budget for ongoing developer support
Result: 10+ months later, system still works. Team never called me for help.
4. Cost Savings > Feature Count
- Initial temptation: Build features to match HubSpot 1:1
- Reality check: They only used 20% of HubSpot's features
- Smart move: Built exactly what they needed, nothing more
- Impact: Faster development + lower maintenance + eliminated waste
5. Know When to Design Yourself vs. Use Frameworks
Critical decision:Comprehensive documentation + simple architecture
- I left for school 2 days after launch
- Team needed to operate independently
- No budget for ongoing developer support
- Public-facing sites (design system expectations)
- Complex dashboards with many views
- Teams with designers (handoff efficiency)
Result: 10+ months later, system still works. Team never called me for help.
Metrics
| Metric | Before (HubSpot) | After (Custom) | Improvement |
|---|---|---|---|
| Annual Cost | $3,800 | $25 | 99% savings |
| Load Time | 3-4s | <1s | 4x faster |
| Data Access | Scattered | Centralized | Problem solved |
| User Limit | 1 ($3,800 per additional) | Unlimited | Infinite scale |
| Uptime | Dependent on HubSpot | 10+ months | Self-sustaining |
| Maintenance | Subscription required | Zero needed | Fully autonomous |
What I'd Do Differently
With more time:
- Email Integration: Auto-log emails from Gmail/Outlook
- Reporting Dashboard: Visual analytics on client health
- API Webhooks: Integrate with accounting software
- Automated Backups: Scheduled database snapshots
What I Wouldn't Change:
- Vanilla JS choice (still the right decision)
- Simple architecture (easy to maintain)
- Feature scope (built exactly what was needed)
- Design approach (daily-use focused)
Conclusion
This project taught me that building internal tools requires different thinking than building products
Products: Need to impress, delight, and convert
Internal tools: Need to be fast, clear, and reliable
The best validation: Team has used it every day for 10+ months without complaint.
The business win: $3,800/year saved forever
The technical win: Code I wrote 10 months ago still works without me.
Built by Adriel Oloko
Linkedin • X [Twitter]