Product Engineer (Contract)

Job Description There is a working product. There is one founder. There is no team yet. The product needs someone to take it the rest of the way — finish the build, harden it, test it, put it in front of the first real users, and stay close enough to those users to know what to fix next. That's the job. It is not a well-defined ticket queue. It's closer to: here is the thing, here is what "done" means, go. This is a paid contract role. We're paying for your time and your expertise, and we expect to pay properly for both. What we're building An orchestration layer that sits above the frontier AI models — Claude, GPT, Gemini — and coordinates them rather than picking one. It is aimed at people whose work product is judgment, where being wrong is expensive and "the AI said so" is not an acceptable answer. Where things actually stand - The core product works end to end. - There's a real documentation and decision-log discipline in place — architecture invariants, contracts, a decision record going back months, git hooks enforcing some of it. You will not be reverse-engineering a mystery. - There are known open bugs, known unfinished surfaces, and a UI that needs an aesthetics pass. - It has never had a user who wasn't the founder. The gap between "works" and "someone else can use this without me sitting next to them" is the gap you're being hired to close. What you'd own Phase 1 — Close it out (first weeks) - Finish the remaining feature work; hide or cut what isn't ready - Aesthetics and UX pass — it needs to feel like a product, not a prototype - Fix the open bug list; expand test coverage - Security hardening pass ahead of real users (external review budgeted separately — you'll work with it, not carry it alone) Phase 2 — Alpha - Ship it to real users - Onboarding: get people from signup to first genuine use without hand-holding - Support them directly. You'll be answering the emails. This is a feature of the job, not a chore attached to it. - Instrument it enough to know what people actually do, versus what they say they do Phase 3 — Beta and beyond - Turn alpha behaviour into the beta roadmap - Help make the call on who this ships to first: individual professionals, small firms, or enterprise - Build the systems and documentation that let a bigger team pick this up later Stack - Frontend: vanilla JS, HTML, CSS — a single-file monolith, no framework. Deliberate. It'll be broken up when there's a reason, not before. - Backend: Supabase (Postgres, auth, storage) - Hosting: Netlify, deploy on push - Provider APIs: Anthropic, OpenAI, Google - Node for tooling and tests If you need a framework to be effective, this isn't your project. If reading 5,000 lines of someone else's JavaScript and immediately knowing where the bodies are buried sounds fine, keep reading. Who we're looking for Someone who uses both sides of their brain. One side reads code carefully. Spots the branch that swallows an error without telling anyone. Doesn't trust a function just because of its name. Can hold the whole system in their head and work out what a change will break three files away. The other side thinks about the person on the other side of the screen. Why they gave up at step three. Which feature they'll ask for and never use. What would make them tell a colleague about this. Most people are good at one. We want someone who is genuinely strong on the code side and has real instinct for the user side — someone who can look at a screen and say "this works, and nobody will use it," and be right. Hard requirement: you have shipped something real inside an agentic coding harness. We mean you have worked inside Claude Code, Cursor, Codex, Aider, or something equivalent — as your main development environment — and something you built that way exists, runs, and has been used by someone other than you. You know how these tools fail. You know what they'll confidently get wrong. You've built your own habits around checking what they produce, because you've been burned by not doing it. Using AI to look things up or to explain code is not the same thing, and isn't what we're asking about. And you finish things. One small project that shipped, got users, and was supported for months tells us more than ten impressive repos that stopped at 80%. We're being direct about this because the failure mode of this role is a beautiful, elaborate, unlaunched product. What we are not asking for - A degree, or a degree in progress, or a degree completed - A specific number of years. Second-year student and twenty-five-year veteran are both entirely welcome, and will be assessed identically. - A recognisable logo on your CV - Deep security or infrastructure specialisation — that's brought in as expertise where it's needed - Prior startup experience The founder covers strategy, product direction, positioning, and go-to-market. What's missing is build capacity and someone who owns getting it in front of users.