👤 Authored by Lashmi Bai Ravindrapandian
📅 Published on Apr 5, 2026
This is my personal experience with Mr. Claude. One day, I had an idea for my son’s abacus practice. I wanted to build an online application around it so that he can practice. That’s all I had in the beginning.
I started with blank slate.
Scroll till the end for the LR Abacus Practice Test App Link.
What Felt Different About Having Mr. Claude as My Developer
I’ve worked with technical and functional teams before, so I understand how development projects normally work.
But working with an AI developer felt very different.
I could explain what I wanted from a user or business perspective. Mr. Claude could work out the technical side.
If something didn’t look right, I could simply point it out.
If something wasn’t working, I could explain what I was seeing.
If I wanted a new feature, I could describe the outcome.
Then Mr. Claude would take it from there.
No scrum board.
No stand-up.
No status meeting.
No action tracker.
No recurring follow-up email.
No sprint tracking.
No major documentation.
No “I’ll get back to you” ping
Just Requirements → Mr.Claude → Build → Test → UAT → Deploy → Feedback → Iterate.
My Customer Was My Son
There was one more thing that made this project interesting.
I wasn’t building the application based on some imaginary customer persona. My customer was right in front of me – my son.
I used him as the primary customer persona while building the app.
I kept thinking about how he would use it, what would make practice easier, what could keep him motivated and what might frustrate him.
That influenced many of the features I asked Mr. Claude to build – different test lengths, Practice and Exam modes, badges, progress tracking, certificates and even the small sound cues.
So while Mr. Claude was my developer, my son was my customer.
That also gave me a very real way to do UAT.
Would my customer actually want to use this?
From an Idea to the First Version of Product
I started with explaining how I wanted the application to work. Prepared a detailed requirements documentation with some do’s and don’ts. Very basic portal for anyone to test their abacus skills.
Created a project using Mr. Claude Code, completed all the basic configuration, guardrails required.
Mr. Claude started with the built of the initial portal with registration, guest access, the abacus test flow and results view.
Something funny happened once the basics started working.
The faster I saw Mr. Claude turning my basic ideas into actual features, the more ideas I started getting.
It felt like a manager seeing an employee getting the work done faster and thinking, “Okay, what else can we get done from this employee?”
That was me. I started adding more and more.
Features I Added Along the Way
- Custom test lengths – 25, 50 and 100 questions
- Practice Mode – untimed practice
- Exam Mode – timed test experience
- 14 achievement badges – based on test history
- Progress dashboard – with visual progress charts
- Printable certificate – unlocked after earning a badge
- Sound cues – timed around the 1-minute and 5-minute marks
- Profile editing page for users
- Change password
- Instant Guest access
- Login and registration
- Test results and history
- Motivational quotes throughout the application
- Responsive design for mobile and smaller screens
- Dedicated homepage explaining the application
- About Me page with my story and links
- LR Abacus Practice Test branding across the application
What started as a simple abacus practice test space slowly became a proper little product with portal.
What Got Set Up Under the Hood
I honestly didn’t know most of these terms when I started. Not anymore.
- Framework: Next.js 16 the core framework the whole site is built on
- Typescript: programming language (a stricter version of JavaScript).
- Styling: Tailwind CSS v4 handles all the visual styling (colors, spacing, layout).
- Database: Neon serverless Postgres database
- Authentication: Custom login system with secure session cookies
- Hosting: Netlify hosts the live site, runs it as serverless functions behind the scenes.
- Version control: GitHub stores the source code
- Icons: lucide-react the icon set used throughout (the little icons next to labels, buttons, etc.).
- Sound: Generated directly in the browser using Web Audio API, so no audio files were needed
- FormSubmit: a free third-party service that receives the form submission and emails it to you; no account/database of ours involved in sending it.
Then Came Deployment
This was a different learning altogether. Here’s the problems we hit and how Mr. Claude fixed them.
- Vercel 404 errors: The build was successful, but the live site returned 404s. Solution: Mr. Claude confirmed it was a Vercel infrastructure issue and suggested moving to Netlify.
- Netlify SSO blocking public access: The application wasn’t publicly accessible as expected. Solution: Mr. Claude identified the SSO configuration and guided me through turning it off.
- Production deployment blocked: Operational credits had run out. Solution: Mr. Claude suggested a draft deployment, verification and then promotion to live.
- Login stopped working: The live function logs showed an
ENOENTfilesystem error. Solution: Mr. Claude traced it to theDATABASE_URLenvironment variable being restricted to the wrong deployment context. - Local file storage issue: Without the database connection, the application was falling back to local file storage, which doesn’t work on Netlify’s read-only filesystem. Solution: Mr. Claude corrected the database environment configuration so the application could use Neon Postgres properly.
- Dropdown not closing: During UAT, I noticed a dropdown wasn’t closing when clicking outside. Solution: Mr. Claude traced the issue to
backdrop-blurcreating a CSS stacking context and fixed it using a React Portal. - Other UI issues: I also found sidebar layout, navigation and mobile-width problems during testing. Solution: Mr. Claude investigated each issue and made the required fixes.
This was where Mr. Claude as my AI developer + my functional UAT worked particularly well.
I didn’t need to diagnose the technical root cause.
I needed to identify the problem from the user’s perspective. Mr. Claude could investigate the technical side.
From Zero to a Live Application
Looking back, the interesting part isn’t really the technology stack.
Yes, the application ended up using Next.js, TypeScript, Tailwind, Neon Postgres, GitHub and Netlify.
I set the rules, guardrails, regulations, instructions, directions to manage the project features I give to avoid rework etc. We had a agreement on how each and every input and output should be written.
The application itself became the centre of the conversation.
I’m still not an app developer.
But I now have something I didn’t have when I started – a live application that came from an idea I had for my son’s abacus practice.
https://abacus-test-portal-lr.netlify.app/
Take a practice test, explore the dashboard and see the experience from a user’s perspective. I’ll happy to know your feedback.
Discover more from LR Virtual Classroom
Subscribe to get the latest posts sent to your email.
One thought on “When My Idea met Mr. Claude”
Comments are closed.