This is Part 1 of 3 in this series about overcoming impostor syndrome by building a complete app.
- Part 1 (this post): The decision and initial planning
- Part 2 (coming soon): Implementation and development
- Part 3 (coming soon): Lessons learned and results
After my last job on the Isle of Man, I went through a rough period where I experienced the dreaded burnout.
A dark period that until then I hadn’t given proper importance to; either way, the path to get out and restore yourself is long and scary.
Mental Health is already a global topic, well developed on social media, so I’ll spare you the details. But yes, the work environment has a big slice of responsibility for employee health.
That said, let’s get to the post and where it all began.
December came and I was at home. Unemployed. Anxiety through the roof. Studying ISTQB because “certification might help with interviews”. Creating flashcards in Anki. Trying to maintain a routine.
And that voice wouldn’t stop:
You jump from branch to branch, you never managed to explain to your family what you do, you never finish a project
I know it’s not true.
Rationally, I know.
I have 10 years of experience. I’ve been a backend developer. I’ve been a systems architect. I’ve worked with many different languages, many incredible companies. But rationally knowing doesn’t make the voice shut up.
Because there was a part that WAS true:
You never delivered a portfolio, a product or an app of your own
And that’s what broke me. Not the unemployment. Not the anxiety. It was realizing I was afraid to try or even have to learn new things.
Yes, learn new things because, anyone after a certain age wants to manage or improve what they already know, the famous specialization.
The Decision
3 AM. Couldn’t sleep. Anxiety high. Opening and closing LinkedIn. Scrolling through job posting after job posting. The vast majority asking for “full-stack”. All asking for things I didn’t have on my resume.
I thought: “I know backend. I know how to create APIs, model databases, architect systems, test systems. Why can’t I create a simple frontend?”
And the answer was quite simple and cruel: because I never really tried.
I was afraid to try and confirm that I was a fraud.
So at 3:17 AM, with my Snorlax slippers and anxiety through the roof, I made a decision:
I’m going to create a complete application. Solo. From scratch. Frontend that I don’t know. Backend that I know. Everything integrated.
And if I failed? At least I would have tried.
The theme? Traffic, I needed to learn to drive on the Isle of Man, get my license and for that I needed to pass the theory test. Well, I create something for my portfolio and as a bonus I study for the test.
A project with more gains than expected.
The Plan: How to Make AI Work For Me?
This is where the story gets interesting.
I didn’t wake up and ask ChatGPT “make an app for me”. That doesn’t work. Never worked. Never will work (Maybe it will, I don’t know). And everyone who tried knows where that leads.
On the other hand I have a block when it comes to using AI for everything, the new serotonin in token format that solves all problems it’s asked still scares me.
Still, I believe we can compare the use of AI to the use of a car, it may seem strange to learn, you’ll never have 100% control, but you can still manipulate and use it for tasks that alone you couldn’t do, in the case of the car, it could be traveling several kilometers with cargo, in the case of AI, it could be writing repetitive code or reviewing what was written. Besides planning of course, which they’ve been doing better and better.
First Thing: Admit What I Didn’t Know
I opened a document and wrote:
WHAT I KNOW:
- Backend: C#, .NET, REST APIs, Entity Framework, PostgreSQL, NodeJs, Typescript
- DevOps: Azure DevOps, CI/CD, Docker, Git, Github
- Testing: Playwright, ReqnRoll, xUnit, NUnit, Jest
- Architecture: Clean Architecture, BDD, SOLID
WHAT I DON’T KNOW:
- Frontend: React Native, Expo, components, navigation
- Mobile: How to structure a mobile app
- Integration: How to make frontend call my backend
- UI/UX: How to create interfaces that don’t look like 2005
WHAT I NEED TO LEARN:
- The basics of React Native (enough not to get lost)
- How to create components
- How to do navigation between screens
- How to integrate with API
Second Thing: Study (But Not Too Much)
I wasn’t going to become a React Native expert in a week or two. Impossible.
But I could understand enough to know what to ask.
I went to YouTube. Traversy Media. “React Native Crash Course”. 3 hours of video.
I watched it at 1.5x speed. Pausing. Taking notes. Not to memorize syntax. To understand:
- How a React Native app is structured
- What components are
- How state works
- What a hook is
- How navigation works
- How to make HTTP requests
I drew many parallels with what I already knew from other technologies, whether Typescript which I already knew and helped a lot in the process, or object orientation to focus on correct interfaces.
I didn’t come out knowing how to do it. I came out knowing how to ask intelligent questions.
And that made all the difference.
Third Thing: Talk to AI (For Real)
Here’s the secret sauce.
It wasn’t:
“AI, create an app for me”
As the rabbit says, if you don’t know where you want to go, any road will take you there.
It was something along these lines:
- Instructions for pair programming and documentation.
- All the technical specification I created
- My knowledge level in each area
- The specific doubts I had
- What I expected to learn in the process
The answer wasn’t code. It was an action plan with dates, what to learn, what to look for, some outdated things, but a starting point
The Journey (And What Nobody Tells You)
Day 1: Backend (The Part I Knew)
I started with what I knew: backend.
Contrary to what I thought I would do, create a backend in .NET 8, clean arch and everything, I decided to go simple, Supabase, the reason is simple: Keep the same language since I’m a solo dev.
I won’t go into too much detail, but supabase allows me to create the entire backend structure in serverless, something I had already worked with in the past and was comfortable dealing with.
And even in my comfort zone, I had moments of “damn, is this even right?”
Starting with the front end I began creating authentication, following tutorials, asking AI if that implementation made sense and what could be improved.
I used another example project (Keycloak, I’ll make a post about it later)
I started using MCPs to feed the AI with information from the local project, the same with context7, sequential thinking, memory and so on.
The AI I used was Claude, in case you’re wondering.
In pair programming moments, I would often create a component, review it with Claude and he would be responsible for other implementations while I worked on other parts like requests to the backend, or interfaces for data transition. and from time to time some questions were asked:
- “Why this approach?”
- “What are the alternatives?”
- “How does this scale?”
- “How would I test this?”
It wasn’t just accepting code. It was understanding code.
And here’s the secret sauce and most important part about coding with AI, as I mentioned above: SEROTONIN.
It feels so good to see the code working and running, as soon as the AI finishes it already offers you a new feature you hadn’t even thought of and how do you hold back from hitting enter?
Think about that for a moment.
Continued in Part 2, where I’ll detail the implementation process, the technical challenges I faced, and how I effectively used AI as a pair programmer.
Stay tuned!