01 / Case study
cellbot
A connected workspace for repair shops and their customers.
I designed and built cellbot to bring repair quotes, bookings, messages, payments and job tracking into one product.
Visit cellbot.chat- Year
- 2026
- Role
- Product design · Full-stack development
- Built with
- Next.js · React · Convex

The problem
What needed to work better.
Many repair shops manage quotes, bookings, messages, payments and job updates across separate tools. That adds admin for staff and makes it harder for customers to know what happens next.
What I built
The result is a connected flow: customers can get a quote and book, while staff manage the repair, payment and updates from the same system.
Project evidence
My role, testing and next steps.
- Ownership and collaboration
- Built with my dad, who contributes first-hand repair-shop knowledge while I lead the product design and engineering.
- Testing evidence
- Automated checks cover permissions, bookings, billing and operational workflows where mistakes create real work.
- What I would improve next
- Run a bounded pilot with repair-shop staff and turn the strongest workflows into measured adoption and time-saving evidence.
Main areas
What I worked on.
- 01AI-assisted website quotes and customer support
- 02Repair CRM and status pipeline
- 03Shop-specific pricing, booking and payment flows
- 04Shopify and standalone customer journeys
- 05Voice, messaging and customer status updates
- 06Responsive operational dashboards
My role
Taking a broad product from idea to working software.
I worked across product planning, interface design and full-stack development. That included the public website, customer journeys, staff dashboards, data models, integrations and the smaller details that make a busy system easier to use.
I also tested and hardened real workflows such as bookings, stock movements, refunds, supplier returns and billing, where a small mistake can create extra work for a repair shop.
Key decisions
Keeping prices and important actions controlled.
Cellbot is multi-tenant, so each shop needs its own customers, prices, staff and settings. I treated that separation as a core part of the product rather than something to add later.
AI helps identify devices, explain faults and support customers, but it does not invent prices. Quotes come from the shop’s own pricebook, and important actions use clear confirmation steps.
The customer and staff sides share the same repair record. This reduces duplicate entry and keeps quotes, bookings, messages, payments and status updates connected.
Working together
Building with repair-shop knowledge.
My dad brings practical knowledge of repair shops and the problems staff face each day. We talk through ideas, test the flows against real situations and decide what is genuinely useful before adding more.
I turn that context into product decisions and working software. The process has taught me to ask better questions, explain technical choices simply and take feedback without becoming attached to my first solution.
What I learned
Testing more than the interface.
The project pushed me to think about permissions, data isolation, payment states, retries, audit trails and testing alongside the interface. Automated checks cover the workflows where mistakes could create extra work for a repair shop.
I use AI tools to support research, planning, debugging and review. I inspect the code, run automated checks and test important flows in the browser before I treat a change as complete.
Tools used
