Here's what Factcovery actually looks like.
Website
Mobile App
App coming soon, pending store review
Lighthouse Report
Honestly, hitting a good Lighthouse score isn't rocket science — but I'm pretty confident AI will nail it more consistently than most of us would on our own.
Factcovery is live at factcovery.com.
First things first — this is NOT vibe coding
There's a way most people use AI that looks something like this: open Claude or ChatGPT, type "build me a todo app", get code back, paste it in, pray it works. When it breaks, paste the error back in. Repeat forever.
That's vibe coding. It works fine for small throwaway tasks. But for a real product — with a web app, a REST API, a mobile app, and CI/CD — it falls apart fast.
What I did was a little different. I used Claude as an AI Agent, which means before Claude writes a single line of code, we plan together first.
The core rule: Plan in plain English → Review → Then build.
Nothing fancy. But that one extra step changed everything about how the project turned out.
What is Factcovery?
Factcovery is an app that aggregates and generates interesting "facts" by topic — bite-sized, accurate, shareable pieces of information you'd want to send to a friend.
The final stack:
- Web: NuxtJS
- API: Django REST Framework
- Mobile: Flutter
- Infrastructure: GitHub Actions + VPS
Total time: ~2 days.
Part 1 — Web with NuxtJS: Plan first, code second
The first step is never code — it's a conversation
Instead of saying "build me a web app about facts", I started with an actual conversation:
My prompt:
"I want to build a web app called Factcovery — where users can discover interesting facts by topic. Target users are 20–35 year olds who like quick reads and mostly browse on mobile. Before writing any code, help me list all the screens we need, the main user flows, and suggest a folder structure for NuxtJS. No code yet — just the plan."
Claude came back with a clear plan: a list of screens, a user journey from app open to sharing a fact, and a sensible folder structure. I read it, adjusted what didn't feel right, and only then gave Claude the green light to start coding.
This is the key point: you make the decisions, Claude does the execution.
UI — Describe the feeling, not the pixels
I didn't say "blue button, border-radius 8px". I said:
My prompt:
"The UI of Factcovery should feel like a modern science magazine — clean, has depth, not too serious. Dark background with amber yellow as the accent color. Typography needs to be readable on mobile. Please propose a simple design system: color palette, font pairing, spacing scale. Then apply it to the homepage."
The result? A consistent design system from day one — not something patched together screen by screen.
Multiple Languages — Plan it from the start
Retrofitting i18n into an existing codebase is painful. This time I asked Claude to plan the i18n strategy before the project structure was even finalized:
My prompt:
"This project needs to support English and Vietnamese from day one. Propose how to organize translation files in NuxtJS, a naming convention for keys, and a workflow for adding new languages later without having to refactor. No code yet — just the approach."
Lighthouse — Build for performance, don't fix it later
Instead of waiting until the app was done to find out the Lighthouse score was bad, I asked Claude upfront:
My prompt:
"For a NuxtJS app that displays a lot of text and images, what are the most common Lighthouse issues? Create a checklist of things to implement from the start to hit 90+ on both mobile and desktop."
Claude returned a concrete checklist. I implemented it while building — not after.
Part 2 — Django Backend: Read the frontend, then write the API
A reverse workflow — that actually makes sense
Instead of designing the API first and making the frontend conform to it, I did the opposite: I used the frontend code itself as input for Claude to infer the data model.
My prompt:
"Here are my Nuxt components and pages [paste code]. From these, infer the Django models needed, the relationships between them, and the minimum API endpoints required for the frontend to work correctly. Output in this order: Models → Serializers → URLs."
The result was a backend that was in sync with the frontend from the very beginning — no discovering missing fields after the fact.
Crawl & Generate Fact Pipeline
This was the most logic-heavy part. I spent the most time on the planning step before letting Claude write anything:
My prompt:
"I need a pipeline: crawl news sources → extract content → use AI to summarize into a short 'fact' → save to DB → expose via API. Design the architecture for this pipeline: what Django models are needed, what task queue to use, error handling strategy, and how to schedule it to run periodically. No code yet — just the architecture in text form."
After reviewing and tweaking the architecture, I had Claude implement it piece by piece.
Part 3 — Mobile with Flutter: Know when to pivot
Tried React Native — and recognized it wasn't the right fit
I started with React Native because I was comfortable in the JavaScript ecosystem. Claude scaffolded the project, I ran it, and the performance wasn't where I wanted it — animations felt sluggish, and the structure was more complex than a relatively simple app needed.
Instead of trying to fix it, I made the call to pivot. This is where human judgment matters more than any prompt.
Switching to Flutter
With Flutter, I started fresh — the right way:
My prompt:
"I'm building the Factcovery mobile app with Flutter. The app has these screens: [list]. Please propose: project structure, a state management solution that fits this app, naming conventions, and how to organize the theme and styles. Explain the reasoning behind each choice."
Claude didn't just give me a structure — it explained why. I read it, understood the reasoning, and agreed before moving forward.
Push Notification System
My prompt:
"I need push notifications for the Flutter app: notify users when there are new facts on topics they follow. Plan the entire flow: from user subscribing to a topic → backend triggering the notification → Flutter receiving and displaying it. Include background handling. Plan first, code after."
Part 4 — CI/CD: GitHub Actions deploying to VPS
This is the part that intimidates a lot of people — but with the "plan first" approach, it's straightforward:
My prompt:
"I have a VPS running Ubuntu and my code is on GitHub. When I push to main, I want to automatically: SSH into the VPS, git pull, run docker-compose up to restart services, then run a health check. Plan this workflow step by step, then write the complete .github/workflows/deploy.yml file. Also suggest how to set up SSH keys securely for GitHub Actions."
Claude wrote the full YAML config, the deploy script, and a guide for setting up secrets. I just read it, understood the flow, and followed the instructions.
What I learned
✅ What worked really well
1. Always ask for a plan before any code
This is rule number one. Any task more complex than "fix this specific bug" should start with a planning conversation. Spending 5 extra minutes on a plan saves 2 hours of debugging.
2. Use the output of one step as input for the next
Frontend code → input for backend design. Backend API spec → input for mobile app. Everything connects in a logical chain.
3. Ask Claude to explain its reasoning
Add "explain why" to your prompts. You don't need to read every line of code, but understanding the reasoning lets you review properly and make real decisions.
4. Break tasks into small pieces — don't prompt everything at once
One giant prompt = mediocre output across the board. One focused prompt per step = higher quality output that's actually reviewable.
⚠️ Where human judgment is still essential
- Deciding to pivot (like switching from React Native to Flutter): AI can't sense that something "feels off" in the context of your specific project.
- Reviewing architecture before implementation: Claude will suggest something reasonable, but you understand the business requirements better than it does.
- Choosing trade-offs: When Claude presents multiple options, you're the one who decides — not Claude.
The real cost of building with AI
Let's talk about something people rarely mention in posts like this — how much it actually costs.
I'm on Claude Pro ($20/month). For a normal day of work, that's more than enough. But building an entire product in 2 days — web, API, mobile, and CI/CD all at once — is not a normal day. I hit the usage limit. Multiple times.
When that happened, I switched over to minimax 2.5 to keep the momentum going - It's free. It handled most tasks just fine, but there were moments where I could feel the difference — especially on the heavier architecture planning prompts where Sonnet tends to reason a bit deeper and stay more consistent across a long context.
So if you're planning something like this: either budget for API usage on top of your Pro subscription, or be strategic about when you use the big prompts. Save the architecture sessions for when you have the strongest model available. Don't waste it on boilerplate.
Total cost was still a fraction of what any freelancer would charge for the same scope. But it wasn't free — just worth being upfront about.
The takeaway
Factcovery wasn't built by a developer who's great at writing code. It was built by someone who knows how to work with AI intentionally.
The difference isn't in the prompts or the tools. The difference is in the mindset: you are the product manager of your own project, and Claude is the best engineer you've ever worked with — as long as you brief them clearly enough.
If you're curious about anything — the project structure, the exact prompts, the mistakes I didn't write about — just leave a comment. I'll answer everything. Building in public means sharing the messy parts too.
Top comments (0)