Lead / Architect (React / React Native)

About 4goo

We're building a social network for web and mobile — think rich user profiles, real-time messaging,
media feeds, and the scale that comes with it. Our backend is Go microservices on Kubernetes, and
every contract between backend and clients is formalised: OpenAPI for HTTP, AsyncAPI for the
realtime layer.

We're building our entire client layer from scratch — web, iOS and Android — as one monorepo owned
by one team. The first commit hasn't been written yet. We haven't launched publicly, the design
system is finished in Figma and being exported to code, and the architecture is completely open.

You'd be the person who decides it.

The Role

You own the client architecture across all three platforms, and you still write code every day —
this is not a role where programming stops.

Next.js on web, Expo on iOS and Android, one monorepo. Most of the UI is written once through a
universal component layer and rendered on both — which is the interesting part and the risky part.
Choosing that layer, deciding where the platform escape hatches go, and keeping the shared path from
degrading into lowest-common-denominator UI is your call and your problem.

The design system isn't something you'll invent. It's finished in Figma, with composition rules, and
it's exported to code — tokens and components generated rather than hand-copied, surfaced in
Storybook. Owning and extending that pipeline is central to the role.

You're the first hire on this team. The patterns you set are what everything else gets built on, and
you'll grow the team from here with real input on who joins.

You'll work with the architect and the backend teams as a peer. The contracts are the boundary
between us — you'll design against them, push back on them, and negotiate changes rather than accept
them passively.

What You'll Work On

- The universal UI layer. Write once, render on Next.js and Expo. Picking the approach, defining
 the escape hatches, and making sure "shared" doesn't quietly become "worse on both" is the
 highest-stakes work on this list.
- The Figma-to-code pipeline. The design system is complete in Figma with composition rules, and
 it's generated into code rather than hand-copied. Keeping generation, Storybook and the running
 apps in sync is ongoing engineering, not a one-off script.
- Contract-first on both surfaces. OpenAPI for HTTP, AsyncAPI for realtime messaging and in-app
 notifications — both generating typed clients that the whole monorepo consumes.
- The session model. Next.js can hold httpOnly cookies; native can't. Secure storage on device,
 token rotation, OAuth through deep links — one coherent model across three platforms, designed
 once and designed correctly.
- The release pipeline. EAS build and submit for native, web deploys, an OTA policy that's
 deliberate rather than accidental, and three platforms on one cadence.
- The decisions still open — see the Stack section. Those are yours.
- The quality bar that keeps "fast" from costing "right." We want to move quickly. That only
 works if the guardrails are real.
- Growing the team — hiring, review culture, and owning how this team works with AI.

What We're Looking For

Must have:

- 7+ years building client applications, including owning the architecture of a product that reached
 real users
- Both sides of the stack, not just one: React Native shipped to the app stores, *and* React on the
 web in production
- Deep TypeScript, and deep React
- You've built or owned a design system that more than one application consumed — and know why the
 second consumer is what breaks it
- You've reasoned about cross-platform code sharing before and can defend a position on it
- You take responsibility by default. You see the gap, you name it, you close it or find who can.
 There's no queue of tickets waiting for you and there won't be one
- You think in products. Architecture serves shipping; "correct" and "shippable now" are sometimes
 different answers, and knowing which one the moment calls for is most of the job

Strong plus:

- Universal / cross-platform UI layers — Tamagui, react-strict-dom, Unistyles or similar
- Storybook used as a real workbench, not a screenshot gallery
- Figma token pipelines, Code Connect, or generated component systems
- Next.js in production — rendering strategy, routing, and where its abstractions cost you
- Expo and EAS in production, including OTA updates
- AsyncAPI or other schema-first event contracts
- Monorepo tooling at a scale where it starts to hurt
- Real-time at scale — reconnection, ordering, backpressure, presence
- Video-heavy or feed-heavy consumer products
- Native modules and Expo config plugins — knowing where the managed workflow ends
- You've hired and grown a team before

Working With AI Agents

We build with AI agents deliberately, and at this level we expect fluency rather than familiarity.

The reason is specific rather than fashionable. The design system is finished. The backend contracts
are fixed and machine-readable. The team is small on purpose. So our constraint isn't figuring out
what to build — it's implementation throughput at a quality bar, which is exactly where agents pay
off and exactly where careless use gets expensive.

So: you know how to structure a repository so agents work well in it, how to scope work so the
output can actually be verified, how to review generated code seriously, and where the leverage
stops. Not "I've tried Copilot."

You'd also own how the rest of the team works this way — the conventions, the guardrails, the review
standards. If you have strong opinions here, lead with them. We're building this way on purpose, and
we'd rather argue about the details with someone who has thought about it.

What Good Looks Like in This Role

In your first month the foundations exist and they're demonstrated rather than described: the shape
of the monorepo, the universal UI approach proven on real screens on both platforms, and the
generated design system landing in Storybook.

Six months in, three platforms ship from one repository on one cadence. The standards are real
rather than aspirational, and delivery didn't stall while you made them so. Decisions are written
down and can be pointed at. And the people joining the team are people you chose.

 

Stack

Decided: React · Next.js · React Native · Expo (EAS) · TypeScript · monorepo · Storybook ·
OpenAPI + AsyncAPI generated clients · WebSockets · GitLab CI

Yours to choose: the universal UI approach · data and caching layer · monorepo tooling ·
testing strategy

Backend is Go microservices on AWS — you won't write it, but you'll negotiate contracts with the
people who do.

 

Interview Process

1. Intro call — what you've owned, and what you'd want to own here.
2. Architecture conversation on the real decisions in front of this team, including the ones we've
  already made. We're interested in how you reason, not whether you agree with us.
3. Offer.

 

What We Offer

- A codebase you start rather than inherit — the first commit is yours
- Architectural authority, given early, and expected to be used
- Real input on who joins the team next
- A small team by design, not by circumstance
- Direct access to decision-makers — no layers between you and the people setting direction
- Remote-friendly, async-first culture
- Competitive compensation based on experience

*In your application, tell us about a technical decision you got wrong and what you did about it.
That's the answer we read first.*