The Problem We Were Solving
A landlord in Coimbatore managing 14 properties came to us with a spreadsheet problem. He had 3 Excel files: one for tenant details, one for rent collection, one for maintenance requests. Every month, reconciling them took 6–8 hours. When a tenant moved out, updating all three was error-prone. He wanted something better but couldn't afford Buildium (priced for US market at $150+/month) or DDA (enterprise only).
This became Techno Tenant — a property management SaaS built specifically for Indian landlords and small property managers.
Week 1–2: Discovery and Architecture
We interviewed 6 property owners and 4 property management firms to validate the problem. Key findings:
- Rent collection tracking was the #1 pain point (100% of respondents)
- Tenant onboarding (ID verification, agreement signing) was #2
- Maintenance request tracking was #3
- Most were on WhatsApp for all tenant communication — any solution needed to integrate or at least export for WhatsApp
- Price sensitivity: willing to pay ₹500–₹2,000/month, not more
With these constraints, we designed the core data model:
Properties
↳ Units (1:N)
↳ Tenants (current + history) (N:1)
↳ Rent Records (monthly, status: paid/pending/overdue)
↳ Maintenance Requests (status: open/in-progress/resolved)
↳ Documents (lease, ID, receipts)
Tech Stack Decision
We chose:
- Frontend: React 18 + Vite + TypeScript + shadcn/ui (our standard stack)
- Backend: Supabase (PostgreSQL + Row Level Security + Auth + Storage)
- Hosting: Firebase Hosting (frontend) + Supabase cloud (backend) — no separate server to manage
- PDF generation: jsPDF for rent receipts (client-side, no server needed)
- Payments: deferred to v1.1 — v1 tracks manually
Supabase Row Level Security (RLS) was critical here. Each landlord (auth user) can only see their own properties, units, and tenants — enforced at the database level, not just application logic. A single policy: tenant_id = auth.uid() gives multi-tenant data isolation without complex middleware.
Week 3–6: Core Build
We shipped the core flows in this order:
- Auth (Supabase magic link — landlords don't want passwords)
- Property + unit CRUD
- Tenant onboarding with document upload
- Monthly rent record generation (auto-creates a "pending" record on the 1st)
- Mark as paid + generate receipt PDF
- Overdue alerts (cron job on Supabase Edge Functions)
Week 7–8: Maintenance and Reports
Maintenance request tracking turned out to be simpler than expected — a ticket system with status and optional photo upload (Supabase Storage). The report screen required more thought: landlords wanted a "rent roll" (all units, current status) and a monthly income summary. We used Recharts for the dashboard charts.
Week 9–10: Polish and Launch
The last two weeks were:
- Mobile responsiveness — landlords check rent status on their phones constantly
- WhatsApp-ready rent reminder templates (copy text → paste to WhatsApp)
- Onboarding flow for new users (a 3-step wizard: add property → add unit → add tenant)
- Testing on real data with our initial client
Results at Launch
- Went live at renttrackr-39023.web.app
- First client reduced monthly reconciliation time from 6 hours to 25 minutes
- 10 properties, 23 units, 20 active tenants onboarded in the first week
- Zero critical bugs in the first 30 days
What We'd Do Differently
- Start with mobile layout — we designed desktop-first and retrofitted mobile. Should be the other way around.
- Add Razorpay from day one — manual payment marking is the biggest friction point; automated collection would have doubled value
- Build the tenant portal earlier — landlords kept asking "can tenants log in?" from week 3
Building Something Similar?
We can build industry-specific SaaS products for Indian markets in 8–12 weeks with a similar approach. Let's talk about your idea →