Fullstack Architect

About C5i

Founded in 2000, C5i enables organisations to make the most effective strategic and tactical moves relating to their customers, markets and competition, at the pace the digital business world demands. We build AI products: Agent5i, our enterprise agentic AI system; Compete, digital shelf analytics for brands selling through retail; Incivus, creative effectiveness for marketing teams; and Synthetic Audiences, virtual respondents for research teams who need an answer faster than a panel can return one. Each has its own users, roadmap, release cycle and stack today, running across Azure, AWS and GCP.

What We Seek

You own the product surface across all four products. Architecture authority and delivery accountability sit in the same seat: you define how the products are built, and you build them. The remit spans the full application layer. Frontend and interaction design for agent-driven interfaces. Backend services and APIs. Agent orchestration, tool and function calling. Integration with the systems tenants already run. Test strategy and release. Everything a user touches passes through your design.

You hold that across four products rather than one line, so your decisions have to generalise and your conventions have to actually get reused. Agent-facing product patterns are not settled anywhere in the industry, so there is limited prior art to copy. You will make design calls on incomplete information, ship them, learn from production and revise. Doing that without ego, and without treating a reversal as failure, is a requirement of this role rather than a soft preference. Two things this seat is measured on: whether a convention written for one product gets used by the next, and whether an interface still holds after a model provider changes underneath it. Product engineering has run for a decade and is being pivoted to agent-native surfaces now, so you will replace as much as you build.

You lead nine engineers across full stack, frontend and backend. Design direction, code review, standards enforcement, and raising the ceiling of the 4 to 8 year band. None of it is a reason to leave the codebase.

Why This Seat

Agent-facing product patterns are unsettled across the industry, so the conventions set here become a reference rather than an implementation of somebody else's. Four products at once is scope a single-product company cannot offer at this band, and a pivot means you delete as much legacy as you inherit. Authority and execution sit together: no review board between your decision and production, and nobody above you to re-litigate it. Nine engineers grow under your standards while your own hands stay in the codebase. Compensation is benchmarked at the top of the band for people who fit this shape.

How We Work

Flat. Most people read architect as a role that reviews and assigns. Not here. Three things decide whether you succeed, and we weight them above any line on your CV.

Proactivity. No groomed backlog. Requirements arrive incomplete and change after you have started building. Find the problem, size it, then solve it, and push back on scope that cannot be delivered in the time available by proposing what can.

Adaptability. You will design an agent interaction pattern in the morning and debug an integration failure in production in the afternoon. Model providers change, frameworks are superseded, product definitions move with them. Treat the churn as normal rather than as a planning failure.

Accountability. You have a team of nine and you still write code. Leading here is design direction and review, not handing work down and waiting on it. When a release breaks, the question is never who built the component. You reproduce it, fix it and ship it.

What You Will Own

• Application architecture: interaction layer, service layer, agent orchestration and model integration, across all four products.
• Agent patterns: multi-agent orchestration, tool and function calling interfaces, and the contracts between the product surface and the model layer.
• API standards: service boundaries and reusable conventions that hold across four products rather than one.
• Frontend architecture for agent-facing interfaces, where the interaction patterns are still being established and there is nothing settled to copy.
• Reusability and replaceability: components and conventions other teams consume, with ergonomics good enough that they get reused rather than worked around, and built to be swapped out rather than lived with.
• Design and code review: technical design sessions, solution reviews and merge review, with your own hands still in the codebase.
• Engineering standards, release quality and test strategy, shared with the Cloud and Data Architect.
• Scoping: turning incomplete requirements from product and delivery teams into architecture that can be built in the time available.
• Technical growth of the team: full stack, frontend and backend, with particular attention to the 4 to 8 year band.

Must Have

• 8 to 12 years building production software, with recent and continuing hands-on development. Bachelor's or master's in Computer Science, Engineering or a related field. Why: the architecture in this seat gets written, not delegated.
• Depth in at least one modern backend stack such as Python, Node.js or Java, and working command of a current frontend framework such as React. Why: everything a user touches crosses both sides. A gap on either one turns into a handover, and handovers are where our products lose time.
• Shipped LLM-backed or agentic applications to real users in production, not prototypes or demos. Why: demos never meet the failure modes, and those failure modes are the actual design problem here.
• Strong grounding in API design, event-driven patterns, microservices and system integration. Why: your conventions have to hold across four products and out into tenant systems, not just inside one repo.
• Led engineering teams of five or more, holding both design authority and delivery accountability. Why: nine engineers work to your standards, and design authority without delivery accountability produces documents rather than shipped software.
• Practical CI/CD, automated testing and release engineering. Why: you own release quality jointly, and quality inspected at the end of a cycle is already late.
• Sound architecture decisions on incomplete information, revised without friction when better information arrives. Why: there is no settled prior art for agent-facing products. Being right later matters more here than being right first.
• Willingness to push back on scope and propose the deliverable alternative. Why: requirements arrive incomplete and move, and silent acceptance becomes a missed release date that lands on this team.

Good to Have

• Developer-facing platforms, SDKs or internal frameworks consumed by other teams.
• Agentic frameworks such as LangGraph, Semantic Kernel, AutoGen, CrewAI or MCP.
• Azure application stack: Container Apps or App Service, AKS, API Management and Entra ID. Equivalent depth on AWS or GCP counts for the same thing.
• Zero-to-one product experience where the process did not exist yet.
• Design-partner exposure where the buyer is technical and sits in the design review rather than behind an account manager.

On the Experience Band

The band is deliberate. Above it we consistently meet people who have optimised for depth in a settled environment, or who have moved far enough from the keyboard that ownership has come to mean assignment. Neither works here.