Careers
Engineering Work. No Role Play.
INX is a small, senior engineering organisation. We are not building a large team. We are building the right one - people who take technical ownership seriously, communicate precisely, and prefer depth of work over breadth of title.
Team Model
Small and senior
Hiring Basis
Selective, not volume-driven
Working Style
High ownership, low ceremony
Working Philosophy
How INX Operates Internally.
These are not cultural aspirations. They are the operational norms that govern how work is done at INX - stated plainly so that anyone considering joining can assess whether they are compatible before the conversation goes further.
Ownership Expectations
At INX, owning a piece of work means owning its outcomes - including the ones that did not go as intended. We do not operate a blame culture, but we do operate an accountability culture. When something you built fails in production, the expected response is: here is what happened, here is why, here is what I am doing about it. Not: here is how the circumstances made this outcome inevitable.
Engineering Discipline
Process exists to serve delivery quality - not to signal effort, demonstrate thoroughness, or create a paper trail. INX runs code review because it produces better code, not because a process chart requires it. Specifications are written before development begins because they produce better systems, not because they are a compliance requirement. When a process stops producing the outcome it was designed for, we change the process.
Communication Standards
INX communicates in writing, precisely, and in advance of problems rather than in response to them. Blockers are raised when they are identified. Scope uncertainty is surfaced before it becomes a delay. Technical concerns are expressed as technical concerns - not as political manoeuvring or relationship management. The standard for communication is: did the person who needed this information receive it clearly and in time to act on it.
Long-Term Thinking
The decisions made in the first two weeks of an engagement shape the system for the years that follow. INX optimises for those years - not for the impressiveness of the first delivery or the comfort of avoiding a difficult conversation about scope. We expect the same time horizon from the people who work here. A decision that saves time this week but costs significantly more next year is not a good decision, even when the person making it will not be around to see the cost.
What INX Values
Six Qualities. Each Observable in Practice.
These are not values listed to appear credible. They are qualities INX evaluates for in the hiring process and relies on in the working environment - because the work requires them.
Systems Thinking
The ability to reason about how components interact - not just whether individual components function correctly. Engineers who think in systems anticipate the failure modes that appear at boundaries, not just the ones that appear within a single service or module.
Applied to: architecture decisions, code review, specification review
Technical Accountability
Owning the outcomes of technical decisions, not just the decisions themselves. This includes documenting reasoning, acknowledging when a decision was wrong, and proposing a correction without requiring the correction to be someone else's idea.
Applied to: delivery commitments, architecture choices, production incidents
Documentation Discipline
Writing down non-obvious decisions as a matter of course - not as an afterthought and not only when the decision is obviously significant. The decisions that seem obvious at the time are frequently the ones that are most costly when they are not recorded.
Applied to: code comments, architecture documents, operational runbooks
Maintainability Mindset
Writing code for the engineer who will read it without context, not for the author who already has it. Choosing the simpler implementation when the complex one does not provide a proportionate benefit. Resisting the accumulation of complexity that is justified individually but unjustifiable in aggregate.
Applied to: code review, abstraction decisions, refactoring scope
Product Ownership
Understanding why a feature exists, not just what it is supposed to do. Raising concerns about requirements that will not solve the stated problem. The ability to distinguish between a well-specified requirement and one that will require interpretation at implementation time - and to surface the difference before development begins.
Applied to: specification review, client conversations, acceptance criteria
Operational Awareness
Understanding that a system is not done when it is delivered - it is done when it has been operating in production without unexpected behaviour. Interest in how the systems you build perform under real load, how they fail, and whether the failure modes are observable and recoverable.
Applied to: monitoring design, deployment planning, post-launch review
Open Roles
Five Roles. Each Described Without Inflation.
Role descriptions state what is actually expected - not what sounds appealing in a job listing. If a role is a match, the description will read that way. If it is not, the description will also make that clear.
Frontend Engineer
Expectations
You build production-quality frontend systems using Next.js, React, and TypeScript in strict mode. You have formed opinions about rendering architecture, component design, and performance profiling - and you can justify them under technical review. You do not treat TypeScript errors as warnings. You write code that the engineer who inherits the codebase in six months can understand without asking you for context.
Collaboration Model
Direct involvement in architecture decisions for frontend systems. You participate in technical specification review before development begins. You review pull requests with the same rigour you expect applied to your own code. You communicate blockers when they are identified - not at the end of a cycle. You are expected to raise quality concerns directly, including on work that is functionally complete but below the standard the system requires.
Ideal Candidate Profile
Three or more years of production React experience. Deep understanding of Next.js rendering models, including SSR, SSG, and React Server Components. TypeScript proficiency at strict mode - you treat the type system as a design tool, not a compliance requirement. You have made architectural decisions that proved incorrect and can describe what you learned without deflection. You have delivered systems that other engineers have maintained, and you understand what makes that go well.
Working Style
You work best with clear technical specifications and defined acceptance criteria. You are more comfortable raising a quality concern directly than shipping work you know is below standard and hoping it passes review.
Full Stack Engineer
Expectations
You are equally comfortable reasoning about database schemas, API design, service boundaries, and frontend architecture. You do not default to the same technology stack regardless of the problem. You understand the operational difference between delivering a system and operating one, and you have done both. You take responsibility for the performance and reliability of what you build - not just its functional correctness.
Collaboration Model
Full ownership of end-to-end features from specification through production deployment. You participate in architecture reviews across backend and frontend decisions. You are expected to make architectural recommendations, document the reasoning behind them, and stand behind them under technical scrutiny. On relevant engagements, you work directly with clients during technical specification phases. You flag scope and technical risk early - not when delivery is already in motion.
Ideal Candidate Profile
Production experience across the stack: PostgreSQL schema design, Node.js or Python service development, React or Next.js frontend. Experience with event-driven architectures or read/write path separation under load. Operational familiarity with deployment environments and monitoring. You have shipped systems that other people maintain and can articulate - specifically - what decisions made that experience good or difficult for the maintaining team.
Working Style
You have a preference for understanding the architecture correctly before writing code rather than refactoring toward correctness after shipping. You document decisions made under uncertainty, not just decisions made with confidence. You are direct in technical disagreements and not defensive when your reasoning is challenged with evidence.
UI/UX Systems Designer
Expectations
You design interfaces for operational software - not consumer products optimised for engagement, not marketing pages. You understand data density, cognitive workflow, and the operational difference between making something look polished and making it usable under load. You produce specifications that frontend engineers can implement without interpretation. You understand component-based design systems well enough to reason about their constraints before you push against them.
Collaboration Model
You are involved from the operational requirements stage - not after engineering decisions have constrained the design space. You work alongside engineers to produce interface designs that reflect the data model accurately, not designs that require the data model to adapt to your visual decisions. You produce specifications with states, error conditions, empty states, and edge cases documented. A mockup that shows only the happy path is an incomplete specification.
Ideal Candidate Profile
Production experience designing interfaces for B2B or operational software - workflow tools, dashboards, administrative interfaces. Proficiency in Figma with the ability to produce developer-ready specifications, not just visual explorations. Understanding of how the interfaces you design are implemented at the component level. You have received critical feedback on design work from engineers and have found that feedback useful rather than adversarial.
Working Style
You are more interested in whether an interface works correctly under operational conditions than whether it renders impressively in a static screenshot. You raise usability concerns even when the client has not flagged them.
Product Engineer
Expectations
You operate at the boundary between engineering and product decisions. You can write production code and you can assess whether a feature is worth building at all. You have a bias toward operational simplicity - the right answer is frequently deferring or removing something rather than adding it. You understand that a decision not to build a feature is as much a technical and operational judgment as a decision to build it.
Collaboration Model
You work with clients and the engineering team to translate business requirements into written technical specifications. You participate in discovery phases directly. You are responsible for ensuring that what is built reflects the operational requirement - not a technically elegant approximation of it that solves a slightly different problem. You write acceptance criteria that can be verified through a deterministic test, not criteria that require interpretation at the point of review.
Ideal Candidate Profile
Engineering background with product delivery experience, or product background with demonstrated technical depth sufficient to write and review production code. Experience facilitating discovery conversations with technically non-specialist clients. Clear, precise written communication - you can explain a technical constraint to a non-technical decision-maker without oversimplifying it. You are comfortable telling a client that what they have asked for will not solve the problem they have described.
Working Style
You ask whether something needs to be built before asking how it should be built. You are more interested in the operational outcome than in the delivery velocity that produced it.
Business Development Executive
Expectations
You develop client relationships with organisations that have defined technical problems and the operational maturity to engage with a structured discovery process. You qualify, you do not pitch. You understand INX's delivery model well enough to explain discovery, specification, and phased development to a technical or executive audience accurately - without overpromising timelines, misrepresenting scope, or describing capabilities that do not exist.
Collaboration Model
You work closely with the technical team to qualify inbound and outbound opportunities. You do not commit technical resources or delivery timelines without engineering input. You manage the commercial relationship from initial contact through to the start of a discovery engagement. You do not compete with the technical team for ownership of an engagement once it has begun - your role transfers to relationship management at that point.
Ideal Candidate Profile
Experience developing commercial relationships for technology services or consulting engagements sold to technical or executive buyers. Ability to discuss software architecture with sufficient depth to qualify a lead accurately - you can distinguish between a scope that is realistic for INX and one that is not. Demonstrated track record of building relationships over time rather than closing transactions at volume. You are comfortable declining an opportunity that is not the right fit for INX.
Working Style
You represent INX accurately even when accuracy reduces the probability of a close. A correctly qualified engagement that succeeds is worth more to INX's long-term position than an incorrectly qualified one that fails.
Engineering Culture
How the Working Environment Is Actually Structured.
Not aspirational statements about what INX is trying to become. An account of how INX operates today - including the aspects that make it a poor fit for people who work well differently.
Small, Focused Teams
INX does not scale to size. Engagements are staffed with the number of engineers the problem requires - which is almost always fewer than a large team would allocate. Small teams produce better communication, clearer ownership, and fewer coordination failures. The cost is that every person on the team carries more.
Low-Noise Communication
INX does not operate a culture of constant availability. Meetings are used for decisions that require real-time discussion. Updates are written. Questions are asked once they are precise enough to receive a useful answer. The expectation is not responsiveness at all hours - it is that communication, when it happens, is clear and carries information.
Responsibility Over Process
Process at INX exists in service of outcomes - not as a system of accountability theatre. Code review exists because it produces better code. Specifications are written because they produce better systems. Where a process no longer produces the outcome it was designed for, the process changes. Where responsibility is clear, extensive process is usually redundant.
Operational Trust
People at INX are trusted to manage their own work - to make decisions within their area without seeking permission, to raise concerns directly rather than escalating through intermediaries, and to identify their own limitations and ask for support when they need it. Trust at this level requires the people it is extended to to be operating in good faith. We assume that until there is evidence otherwise.
Technical Depth Over Title
INX does not have an elaborate hierarchy. Technical decisions are made by the people with the most relevant expertise, not by the people with the most senior title. Disagreements about technical direction are resolved by reasoning about the problem - not by reference to organisational authority. The person with the best argument wins the argument, regardless of their role.
Hiring Philosophy
Three positions on how INX approaches hiring.
On Selectivity
INX would rather be understaffed than incorrectly staffed.
A hiring decision that introduces the wrong person into a small team is more costly than an open role. We do not fill positions under pressure. We do not lower the bar when the search takes longer than expected. The team that exists is responsible for the work that exists - adding someone who requires significant management overhead does not improve that situation.
On Evaluation
We evaluate how you think, not only what you know.
Technical knowledge can be acquired. Reasoning processes are more durable. INX is more interested in how a candidate approaches a problem they have not seen before than in their familiarity with technologies we happen to use. The hiring process involves a practical component that asks you to reason through a real problem - not to demonstrate preparation for an anticipated question.
On Long-Term Fit
We are not looking for someone to fill a role. We are looking for someone who wants to do this work.
The distinction matters. Someone filling a role is optimising for employment. Someone who wants to do the work is optimising for the quality of the output. INX is structured for the latter. If the work described on this page is not genuinely interesting to you - the operational problems, the system architecture, the discipline around documentation and deployment - then the fit is probably not right, regardless of the technical match.
Apply
If the Work Described Here Is What You Want to Do, the Process Is Straightforward.
Introduce yourself by email with a specific account of the work you have done that is most relevant to the role you are applying for. Not a resume summary - a direct explanation of what you built, what decisions you made, and what you would do differently. That is how the conversation will proceed, so starting with it saves time for both parties.
INX does not use a formal application system. Contact is through email. Response time varies depending on current hiring activity. If a role is not currently open, send the email anyway - the right fit is worth a longer timeline.
Introduce yourself with specific work examples
Explain decisions made, not tasks completed
No cover letter required - direct email preferred
Role match assessed through a practical conversation