The Idea: Expert Booking Service
It all started with a simple thought — build a platform for booking expert consultations. Something like Calendly, but "adapted for the Russian market" (spoiler: I didn't know what that meant). Lawyers, psychologists, consultants, coaches. Experts create slots, clients book them — seemed obvious.
I named the project expert-booking.ru. Chose TypeScript full-stack — a familiar tech stack where I could move fast. How fast became clear later, when I discovered I'd flown past the target at supersonic speed.
expert-booking.ru stack: Node.js + Express, React 18 + Vite, PostgreSQL + Knex.js, TypeScript, Docker, YooKassa (stub), Feature-Sliced Design on the frontend.
Version One: Perfect Code for Non-Existent Users
I dove into development with the enthusiasm of a surgeon preparing for the most complex operation. Code grew. Features expanded. Architecture improved. The result was a full-fledged platform for people I hadn't met yet:
Backend (~1,600 lines of code):
- 14 database migrations (users, experts, bookings, payments, reviews, support tickets)
- 12 API modules (auth, bookings, payments, admin, analytics, UTM tracking)
- YooKassa integration stub
- JWT auth with roles (client/expert/admin)
Frontend (~31,000 lines of code):
- Full-featured admin panel with analytics
- Expert dashboard with calendar and statistics
- Booking system with payment confirmation
- Feature-Sliced Design with ESLint architecture validation
- Responsive interface with Tailwind CSS
Infrastructure:
- Docker Compose for local development
- Nginx + SSL for production
- Automated deployment scripts
- Redis for session caching
Everything worked perfectly. Ready to launch. I even wrote a 21-page marketing strategy with a plan to reach ₽1M monthly profit in 18 months — a document no one will ever read except me in moments of quiet sadness.
Problem: when the platform was ready, I got stuck. Like an astronaut perfectly prepared for flight but who forgot to build a rocket.
Stuck not on code — on marketing and business.
The strategy looked beautiful on paper (even better in PowerPoint):
- Stage 1: Attract 20 experts, complete 100 consultations
- Stage 2: Scale to 100 experts, 1000 consultations per month
- Stage 3: Launch referral program, B2B direction
- Stage 4: Geographic expansion, AI recommendations (because you can't do without AI in 2024)
But when it came to the first step — finding those 20 experts — I realized I'd made a perfect plan for conquering Everest without ever leaving home.
Who would I sell this to? How to find experts? How to convince them to abandon working Calendly or Telegram bots? What pain am I actually solving? Turned out the only real pain was my own, from realizing the scale of self-deception.
Main mistake: I wrote 32,600 lines of code and a 21-page marketing strategy for imaginary users. Never talked to a single expert before starting development.
Attempt Two: Or How I Stepped on the Same Rake, But in Python
A few months later, I decided to try again. This time everything would be different:
What changed (in theory):
- Platform: FastAPI instead of Node.js — because when you have a hammer, everything looks like a nail
- Name: slot-me.ru — shorter, easier to remember (still, nobody remembered it)
- Strategy: first find at least 3-5 real users, then write code
Switched to FastAPI because Python is my comfort zone. Instead of fighting ESLint, FSD architecture validation, and monorepo configuration, I could focus on... you guessed it, architecture again.
Main change: Started with conversations, not code. Interviewed several expert friends: what they use for bookings, what problems they face, how much they'd pay, whether they'd try a new service right now.
Main Lesson: Code is 5% of the Project (But I Wrote All 100%)
slot-me development took... much longer than I planned to say in this article.
Honestly, I went back into code. Not for a week, but for months. Not an MVP, but a production-grade platform. But at least this time with different motivation — now I knew I was deceiving myself, but continued doing it consciously.
What was built in slot-me:
- FastAPI backend (196 tests, 56% coverage)
- React frontend with Feature-Sliced Design
- 27 database migrations
- OAuth via Google and Yandex
- Google Calendar and Yandex.Calendar integration
- Email notifications (SMTP/SendGrid)
- Reminder system with APScheduler
- CI/CD pipeline with auto-deploy
- Production configuration with Nginx and Sentry monitoring
11 development stages, all completed. MVP 100% ready. Users 0% ready.
And here's the painful confession: it wasn't even about money. It was about proving to myself (and, let's be honest, my portfolio) that I could do it.
I wasn't looking for clients. I was playing an RPG called "Project Architecture". Like Factorio, but with real code: try FastAPI instead of Node.js, set up OAuth with two providers, write 196 tests with 56% coverage. Instead of the hypothesis "people need this" — the challenge "I can build this without legacy".
And you know what? It was good entertainment. Like a computer game where you level up skills, try new technologies, build perfect architecture without production pressure and legacy code. 11 technical documents, automatic backups, health checks — all this wasn't painful procrastination, but a conscious game of "creating the perfect product".
The problem was one: I called this game a "startup".
But this time I understood the main thing: code is no more than 5% of project success.
The other 95% is:
- Finding real users (not imaginary ones)
- Idea validation — does the problem actually exist?
- Marketing — how do people learn about the service?
- Sales — how to convince them to try?
- Support — how to retain those who started using it?
I was looking where it's light, not where I lost it. I wrote code because it's clear and comfortable. But avoided the most important thing — talking to people, cold calls, testing hypotheses on real audiences.
Developer trap: It's easy to dive into writing perfect code because it's a zone of control. Marketing, sales, talking to strangers — uncomfortable. But without that, the product is dead.
Architectural Procrastination as Art
Look at the numbers from the first project:
- Backend: 1,600 lines — reasonable for MVP
- Frontend: 31,000 lines — this is not MVP anymore, this is a symphony of self-deception
Why so much? Because I turned architectural procrastination into high art:
- Set up Feature-Sliced Design with strict layer validation (for a non-existent team)
- Wrote ESLint rules to ban deep imports (for myself alone)
- Created a full admin panel with dashboards and analytics (graphs with zero metrics look especially sad)
- Implemented UTM tracking and marketing campaign system (to track traffic that doesn't exist)
- Added a referral program (users can invite other users who also don't exist!)
All this before the first user. Like building an airport in the desert and waiting for planes to arrive on their own.
But honestly, it was fun. Feature-Sliced Design with layer validation — an interesting architectural puzzle. UTM tracking and marketing campaigns — trying a technology I hadn't used before. Referral program — why not, if I'm already writing everything else?
This isn't classic developer procrastination. This is conscious architecture play. Sandbox mode of development where you can experiment with technologies without deadline pressure, legacy, and real users. Factorio for programmers.
What's Next: Graveyard of Hopes and Production Server
Right now slot-me is deployed in production. Works flawlessly. Tests green (196 out of 196). CI/CD configured. Sentry monitoring vigilantly watches... silence.
Number of real users: 0.
Because I still haven't started looking for them. The platform is ready to accept thousands of users. Infrastructure can handle the load. But instead of users — just me, periodically logging in to make sure everything still works.
Here's the main paradox of my one-man theater:
I wrote a reminder system that meticulously sends emails 24 hours, 1 hour, and 15 minutes before meetings. But there are no meetings. The system reminds emptiness about emptiness.
I set up OAuth via Yandex and Google so users could log in with one click. But there's no one to click. A beautiful door to an empty house.
I wrote 11 technical documents describing architecture, deployment, monitoring. The only reader is myself, when I forget how it all works.
I'm doing this for myself — to prove I can. This is code therapy. But it's not business.
Reality: All features I described as "user requests" — I made them up myself. Reminders, dashboards, calendar integrations — all my own hypotheses about what might be needed.
The real work begins now: find the first person willing to try. Not a "persona from Customer Journey Map", not "key audience aged 28-45 with income $1,000-4,000/month", but a living person — with a name, phone, real problem, and willingness to give me five minutes of their time.
Conclusions
What I learned from two projects:
-
Code is 5%, the rest is business and people. You can write 32,600 lines of perfect code, but if no one uses it — it's just a hobby project.
-
Don't look where it's light, look where you lost it. Developers often avoid uncomfortable tasks (marketing, sales) and retreat into code. That's a dead end.
-
Work with real people, not imaginary ones. Five conversations with potential users will give more insights than a month of designing in a vacuum.
-
Choose a familiar stack for MVP. TypeScript full-stack with FSD architecture is a great choice for production, but for the first version, iteration speed matters more. 31,000 lines of frontend in the first project vs a few hundred in a minimalist interface in the second.
-
MVP is not about a week of development. It's about a week to put something in the hands of real people and get feedback. Then the real work begins.
-
Marketing strategy on paper ≠ reality. You can write a 21-page plan with metrics, stages, and goals of ₽1M. But if you can't find the first 20 users — the whole strategy is useless.
-
"Development sandbox" is not business. Sometimes developers write code not for users, but to play with technologies in a clean environment without legacy. This is normal and even useful for skill development. But call things by their names: it's not a startup, it's a playground for architecture experiments.
My personal project graveyard:
- expert-booking.ru — rests in peace. 32,600 lines of code, 21-page strategy, 0 users. Epitaph: "Perfect architecture for a non-existent product".
- slot-me — still technically alive. Deployed in production, 11 stages, 196 green tests, CI/CD, monitoring. 0 users. Epitaph not required yet, but the draft is ready.
What's next:
This article is the first step to honesty with myself. Like a doctor has a graveyard of patients, every developer has a graveyard of projects that died from their decisions. I finally came to my graveyard and admitted: these projects didn't die from bad architecture. They died because they were playground projects that I tried to pass off as business.
I got what I was after: leveled up skills, tried modern technologies without legacy, played with architecture like Factorio. It was useful and interesting.
The problem was different: I called it a "startup" and convinced myself it was about money and users. But actually, it was a sandbox for experiments.
Now I need to decide: either turn slot-me into a real product (find first users, test real hypotheses), or honestly add it to my portfolio with the tag "technical playground" and stop confusing play with business.
If you're an expert and you really need a service for client bookings — write to me. Maybe you'll become that first real user for whom all this was worth writing.
