This is Uncover — a free tool that helps senior technical people surface expertise they've stopped noticing, built serverless from prompt to deploy. Try it live, then come back here for exactly how it was built: prerequisites, cost, the real steps, and the bugs that actually happened.
I built it serverless on purpose — a mix of real constraints and real benefits:
Most AI tutorials start with tools. This one started with a question: what could I build using expertise I already had, learning only the missing pieces the project actually demanded?
I'd been writing about two ideas — just-in-time learning, and generating your own roadmap instead of waiting for one. I wanted to test both on myself, out loud, instead of just writing about them. Uncover became the experiment.
The full version of that story is at the end. Here's the build first.
Most of the code was generated with Claude — but the architecture, the testing discipline, and the judgment calls when something broke were the actual work. That work still assumes you know the shape of the stack, even if you've only gone deep on one piece of it.
"You don't need to be an expert in everything. Just one thing."
Which is really the answer to "what tech would I need for this" — not everything, just enough in one area, plus the willingness to learn the rest as it comes up. Here's where that willingness actually got tested.
This is the order we actually did it in — idea first, prompt second, code last. The gotchas are noted right where they happened, not saved for later. Click any step to open it, or use the links below to see everything at once.
This is the shape of the cost for a stateless serverless app like this one — mostly free, with one line item that scales with real usage.
These are honest estimates, not a stopwatch total. Most of it happened in short, real windows — not one clean sitting — which is closer to how most people will actually build something like this.
The gotchas from this build, walked through in full — module resolution errors, deployment protection, environment variables, and the timeout math that actually explains a slow response.
Stuck on any of this, or just want to say hi? Ping me directly — help@femgineer.com or on X, @poornima.
A few posts back I wrote about just-in-time learning — that you don't need to learn everything, just enough to stay ahead, and that it's fine to be a season late. Then I wrote about role clarity — that nobody's coming to hand you a roadmap, you have to generate it yourself. I wanted to actually test both of those on myself, out loud, instead of just writing about them. So I gave myself five honest questions and one weekend to answer them.
Turns out, more than I expected — a working prompt, a backend, a landing page, and a real deployed tool. Not because I had more time than usual. I had less. Between nap times and after-bedtime, the actual work happened in maybe five to seven real hours, not one clean sitting. If it can get built in the cracks like that, the excuse of "I don't have time" gets a lot smaller.
Close to nothing to host, and pennies per use for the AI calls themselves — the real breakdown is above. That mattered to me specifically because I wanted permission to experiment without it needing to become a whole financial commitment first.
Less than I assumed going in, and less than most "learn AI development" courses imply. I already knew the shape of a stack — frontend, backend, hosting — from years of engineering work I wasn't actively using day to day. What I didn't know going in (prompt design, serverless functions, wiring the Anthropic API) I learned exactly when the project asked for it, not before. That's just-in-time learning, not as an essay this time, but as the actual thing I did.
A few, and some surprised me: I hadn't touched serverless deploy specifics in years, Node's stricter module rules bit me twice, and I learned Vercel has a security setting that can quietly block your own live API. None of it showed up until the code was actually running — which is its own lesson. You can't always learn a gap before you hit it. You can only get faster at closing it once you do.
Genuinely more capable, in a way that had nothing to do with the code itself. I felt something similar this past winter, re-learning to ski so I could keep up with my 8-year-old on the slopes — the actual skill mattered less than proving to myself, again, that I could still pick something up. At this stage of life, those small, real wins are doing more for my confidence than they used to. Building Uncover was the engineering version of the same thing.
None of this makes me an AI engineer, and it didn't need to. I used expertise I already had — years of it — to build something new, faster than I expected, for less than I feared. That's the whole idea behind Femgineer: you don't need to master every layer of the stack. You need enough expertise in one area to recognize what good looks like, and enough curiosity to learn the rest. Uncover turned out to be evidence of that, not just a demonstration of it.
This build was basically a live example of it — backend expertise plus a weekend's curiosity, shipped as a real, working tool. If you want a structured way to do that with whatever you know, Ship It is the series for it.
Ship It is not another AI tooling course. It helps you identify a problem grounded in your experience, shape the smallest useful solution, and move it from idea to launch.
Want more from this specific build? Validation steps for both the tutorial and the app itself — the checks worth running before you trust either one — are going out to the Ship It list. Join, and they'll land in your inbox.