Fractional Fullstack Product Engineer

March 7, 2026

Other Jobs To Apply

No other job posts for this day.

<h2>Location</h2> United Kingdom <h2>Employment Type</h2> Contract <h2>Location Type</h2> Remote <h2>Department</h2> Product <h2>Deadline to Apply</h2> March 27, 2026 at 1:00 PM EDT <h1>About the Role</h1> We’re building the core of the platform: a 10-step coaching flow where founders move from unstructured input through AI-generated pitches, explicit challenge, and strategic planning. The system is a governed state machine with LLM integration at its core. It deliberately introduces friction — it refuses to let founders skip past uncomfortable decisions or bypass strategic commitments. The platform treats AI as a powerful but unreliable tool that requires governance, cost tracking, and human oversight. The codebase is essentially greenfield with solid foundations already in place: authentication, CI/CD, structured logging, feature flags, monitoring, and a well-modelled PostgreSQL schema. You’d be stepping into a clean, well-structured project where you can help shape the architecture. <h1>What you’d work on</h1> We have clear milestones and a well-maintained backlog. Likely initial workstreams include: <ul> <li>LLM integration pipeline — building the routing layer that connects the platform to frontier models (OpenAI, Anthropic) via Vercel AI SDK, with streaming responses, cost tracking, and governance </li> <li>Core coaching flow — implementing the step-by-step journey where founders provide input, receive AI-generated pitches, face explicit challenges, and make binding strategic decisions </li> <li>Database modelling and state management — translating domain concepts into a normalised PostgreSQL schema that encodes business rules and enforces sequencing </li> </ul> You’d take ownership of discrete chunks of work end-to-end. There are requirements from the product and business, but you have genuine creative freedom in how you implement them. We want people who raise their hand, make suggestions, and ask questions — not people who silently take tickets and implement exactly what’s written. <h1>The stack</h1> <ul> <li>React Router v7 (Remix lineage) with TypeScript </li> <li>PostgreSQL with Drizzle ORM </li> <li>Tailwind CSS with shadcn/ui components </li> <li>Vercel AI SDK for LLM integration (OpenAI, Anthropic) </li> <li>BetterAuth for authentication </li> <li>GitHub with linear history, commit signing, and CI/CD via GitHub Actions, deploying to Render </li> <li>Sentry with OpenTelemetry for monitoring </li> <li>Vitest and Playwright for testing </li> <li>pnpm workspaces for monorepo structure </li> <li>Devenv/Nix for development environment (Docker available as alternative) </li> </ul> <h1>Hard requirements</h1> These are non-negotiable. If you don’t meet them, we won't be able to consider your application. <ul> <li>Production experience with PostgreSQL. You need to understand normalised schema design, foreign keys, indexes, migrations, and the trade-offs between different approaches (e.g. UUIDs vs serials as primary keys). If you’re primarily a MongoDB or Firebase developer, this isn’t the right role. </li> <li>Production experience with React and server-side rendering patterns. We use React Router v7 (Remix lineage) with loaders, actions, and nested routing. You don’t need prior React Router v7 experience specifically, but you must understand SSR and data loading patterns, and be ready to work with loaders and actions from day one. If your instinct is to add REST API endpoints alongside the framework, this isn’t the right role. </li> <li>Strong TypeScript skills. We avoid stringly-typed code. Types are documentation. You should be comfortable with discriminated unions, generics, and using the type system to prevent bugs rather than just satisfying the compiler. </li> <li>API integration experience. You’ll be building the LLM routing layer that integrates with multiple providers. You need solid experience designing and consuming APIs, handling streaming responses, managing error states, and architecting systems with clear separation of concerns. </li> <li>Exceptional English, written and spoken. This is a remote team doing complex technical work. Written communication is how we coordinate — your commit messages, PR descriptions, and Slack messages need to be clear, precise, and professional. We also work through video calls discussing technical architecture, and you need to be able to communicate complex ideas clearly in conversation. Regional accents are welcome; clarity is essential. </li> <li>Discerning use of language models. We have company Anthropic and OpenAI accounts, Claude Code, and skills that encode our processes — from landing pull requests to scaffolding from Figma designs. We're a small team with ambitious goals, and LLMs are a key enabler for doing more with less. But we need someone with enough production experience to know when a model is producing unmaintainable code, impose the right guardrails, and distinguish a plausible answer from a correct one. The tool is powerful; we want someone with the judgement to wield it well. </li> </ul> <h2>Nice to have</h2> <ul> <li>Experience with LLM integration, streaming responses, or AI product development </li> <li>Familiarity with observability and governance patterns (OpenTelemetry, structured logging) </li> <li>Experience with Drizzle ORM or similar TypeScript ORMs </li> <li>Familiarity with state machine patterns or domain-driven design </li> </ul> <h1>How we work</h1> Fully remote. We communicate via Slack and video calls. Design work lives in Figma. All work is tracked in Linear. Code goes through GitHub with full CI/CD — land a pull request and it’s live on Render. We embrace the heart of Agile — collaborate, deliver, reflect, improve — without the ceremony. No planning poker. No two-week rituals for the sake of it. We size work relative to previously delivered tasks and forecast based on measured velocity. Lightweight process that actually helps rather than getting in the way. A few principles we take seriously: <ul> <li>Transparency by default. Project communication happens in shared channels. When we onboard someone new, they should be able to read back through the channels and get up to speed without anyone replaying conversations. </li> <li>Small leaps, committed landings. When we commit to a piece of work, the scope is agreed and the designs are understood. While you’re implementing, the target doesn’t move. If something needs to change, it goes into the next batch. </li> <li>Ownership, not delegation. Each piece of work has a single owner who drives it to completion. That means talking to Matt about requirements, Laura about design, James about technical approach. We don’t want everything routing through a single bottleneck. </li> <li>Over-communication. We pride ourselves on making sure everyone has the context they need. Async progress updates (progress, problems, priorities) replace stand-up meetings. If you’re blocked, say so early. If you disagree with an approach, raise it. If you spot a better way, suggest it. </li> <li>Considerate coding. We think about the impact of our actions on the rest of the team. We have database triggers that set updated_at timestamps automatically, and tests that check every table with an updated_at column has the trigger present. We recognise we’re fallible and use the tools available to prevent mistakes — for ourselves and for each other. </li> <li>Productivity over presence. We care about what you ship, not when you’re online. Flexible hours, asynchronous by default, with enough overlap for meaningful collaboration during UK working hours. </li> <li>Treat your process like your product. We ship a version of how we work, get feedback, and iterate. Retrospectives are lightweight but genuine. If something isn’t working, we change it. </li> </ul> Our most recent developer shipped to production in her first week. We’d expect the same from you. <h1>The team</h1> <ul> <li>Matt — Founder, product lead. Owns the coaching methodology and product vision. </li> <li>Mike Harris — Founder. The methodology and strategic experience behind the platform. </li> <li>Tariq — Founder. </li> <li>James — Fractional CTO. Architecture, technical leadership, code review, day-to-day collaboration. You’d work closely with James. </li> <li>Laura — UX/Product Designer. Owns the user journeys and interaction design in Figma. </li> <li>Christa — Developer. Working on feature implementation. </li> </ul> <h1>Engagement details</h1> <ol> <li>Start: Early to mid-March 2026 </li> <li>Duration: Through to July initially, with strong potential to continue </li> <li>Commitment: 3–5 days per week (flexible based on fit) </li> <li>Location: UK based, or Europe with exceptional English and significant UK hours overlap </li> <li>Rate: Depends on experience and location </li> <li>Contract: Direct with IconicShift (no intermediaries) </li> </ol> <h1>Interview process</h1> <ol> <li>Initial screening based on your application </li> <li>90-minute live pairing session with the CTO — we’ll hack on a real problem together using a cutdown version of our real production stack. This is the interview that matters. Come prepared: understand React Router v7 loaders and actions, be ready to model a PostgreSQL schema, and bring your normal development setup including any AI tools you use. </li> <li>Founder call </li> <li>Offer </li> </ol>

Back to blog

Common Interview Questions And Answers

1. HOW DO YOU PLAN YOUR DAY?

This is what this question poses: When do you focus and start working seriously? What are the hours you work optimally? Are you a night owl? A morning bird? Remote teams can be made up of people working on different shifts and around the world, so you won't necessarily be stuck in the 9-5 schedule if it's not for you...

2. HOW DO YOU USE THE DIFFERENT COMMUNICATION TOOLS IN DIFFERENT SITUATIONS?

When you're working on a remote team, there's no way to chat in the hallway between meetings or catch up on the latest project during an office carpool. Therefore, virtual communication will be absolutely essential to get your work done...

3. WHAT IS "WORKING REMOTE" REALLY FOR YOU?

Many people want to work remotely because of the flexibility it allows. You can work anywhere and at any time of the day...

4. WHAT DO YOU NEED IN YOUR PHYSICAL WORKSPACE TO SUCCEED IN YOUR WORK?

With this question, companies are looking to see what equipment they may need to provide you with and to verify how aware you are of what remote working could mean for you physically and logistically...

5. HOW DO YOU PROCESS INFORMATION?

Several years ago, I was working in a team to plan a big event. My supervisor made us all work as a team before the big day. One of our activities has been to find out how each of us processes information...

6. HOW DO YOU MANAGE THE CALENDAR AND THE PROGRAM? WHICH APPLICATIONS / SYSTEM DO YOU USE?

Or you may receive even more specific questions, such as: What's on your calendar? Do you plan blocks of time to do certain types of work? Do you have an open calendar that everyone can see?...

7. HOW DO YOU ORGANIZE FILES, LINKS, AND TABS ON YOUR COMPUTER?

Just like your schedule, how you track files and other information is very important. After all, everything is digital!...

8. HOW TO PRIORITIZE WORK?

The day I watched Marie Forleo's film separating the important from the urgent, my life changed. Not all remote jobs start fast, but most of them are...

9. HOW DO YOU PREPARE FOR A MEETING AND PREPARE A MEETING? WHAT DO YOU SEE HAPPENING DURING THE MEETING?

Just as communication is essential when working remotely, so is organization. Because you won't have those opportunities in the elevator or a casual conversation in the lunchroom, you should take advantage of the little time you have in a video or phone conference...

10. HOW DO YOU USE TECHNOLOGY ON A DAILY BASIS, IN YOUR WORK AND FOR YOUR PLEASURE?

This is a great question because it shows your comfort level with technology, which is very important for a remote worker because you will be working with technology over time...