Principal Software Architect

What This Role Is

Every year, millions of students make a decision that sets the direction of their lives: where to study, what to study, and which country they will build a career in. That decision runs through a counselor's office, a university's admissions funnel, a family's conversation with an advisor, and a visa timeline — and almost none of the signal from one step reaches the next. Manifest exists to connect that journey, and it does it through products that each serve one part of it exceptionally well.

This role owns how all of those parts fit together. As Principal Software Architect, you take full ownership of system design across every business unit — service boundaries, data models, auth, and the integration contracts between the products, the shared layer and the AI line — accountable for one thing above all: making the engineers who build those products successful at what they are trying to do. You go deep on the whole — how it actually works, where it is fragile, what "success" means for a system rather than a feature — and you design the standards and contracts that deliver it.

This is an individual contributor seat. No direct reports. Your leverage comes from how completely you understand the system, how good the decisions you write down become, and how well you bring the rest of the business along with you. That combination is deliberate: the moment this role acquires a reporting line it becomes a delivery function, and the thing we actually need disappears.

You report to the SVP of Engineering. You are assessed on two things: the coherence of the system you're designing and the engineering-outcome metrics aligned to it — the measures of whether integration across the portfolio is getting cheaper rather than more expensive. Both move together, and both are how your performance is judged.

You do this across a larger system. Manifest is several products becoming one connected whole, with a shared intelligence layer running underneath. You don't own any single unit's roadmap or its delivery — but you understand the portfolio deeply, you know how every unit connects to the others, and you design in a way that draws on the shared layer and feeds signal back into it. Your scope is the whole by design. Your respect for each part of it is not optional.

How the Role Grows

You own the architecture as the system is today, not as it stays. As the business evolves and as you grow, the scope moves — a new product line, a new regulatory regime, a new generation of agentic systems — typically on a twelve- to eighteen-month horizon. Changes are deliberate, not arbitrary: they happen when a part of the system reaches a stable state you've brought it to, and they're a mutual decision between you and the SVP of Engineering, weighing what the business needs against where you want to grow. You won't be pulled off something mid-flight the moment it starts working. It's how Manifest puts its strongest technical thinking where the business needs it most, and it's how you build range: the architect who has gone deep on the shared layer, then the data platform, then the agent products understands this ecosystem in a way almost no one else can. The constant is the mandate — own the design of the whole, make the engineers inside it successful, and keep this an individual contributor seat rather than a delivery function.

What Makes This Role Different

Most architecture roles ask you to review a backlog of designs. This one asks you to own an outcome for a specific set of users — the engineers building every product here — and design whatever it takes to get there, including the standards that make it stick, and including the agentic architecture this company has never had before.

The leverage is the Manifest ecosystem. You are not designing for your users from scratch and in isolation. You have a shared intelligence layer to build on, signal from across the portfolio to draw on, and a company that is AI-native from first principles. That means you can design contracts, boundaries, and agentic systems that a single-product architect could never see well enough to design.

The timing is the argument. Across Manifest's units, AI is at the point where it stops being a feature and becomes the way the product works, and the integration surface that carries it is being drawn this year. The person who defines that, now, sets the direction for years.

What's Hard — And Why It's Worth It

The best engineers we know are drawn to the hard version of a problem, not the safe one. So here's the honest shape of it.

You design for the whole, but every product team has its own gravity and its own deadlines pulling against it. Getting what the system needs sometimes means making your case against someone else's, and not always winning — and you do it with no reports and no veto, which means everything you achieve, you achieve by being right in a way other people can use. That friction isn't noise. It's what forces the sharpest thinking you'll do here, and the architect who learns to fight for the system while strengthening each product becomes the rarest kind of operator this company has.

The lead who runs a product knows their codebase cold and has their own conviction about the design. Sometimes your judgement will say they're wrong. The moment you tell them that — in the language of their own product — and come out with their trust intact is the moment you stop being an architect who advises and become one engineers actually follow.

And because nobody has held this before, you'll inherit the system mid-stride: decisions you didn't make, commitments already live, and design knowledge about to leave with the people who hold it. Deciding what to keep, what to kill, and what to reimagine — without burning the trust that came before you — is how you build the range almost no one in this market has.

None of this is the easy version of an architect job. That's exactly the point.

What You Own

System design across platforms

• Service boundaries, data models, auth, and the integration contracts between the business platforms, Manifest Intelligence and the AI products
• The written map of what talks to what and where it is fragile — the thing nobody has today
• The design of how agentic systems sit inside deterministic ones: what an agent can reach, how it is observed, and what the blast radius is when it is wrong

Technical standards

• How we build, test, instrument and document — written down and carried by review rather than preference
• The quality bar for what "done" means across teams that currently each define it themselves

The architecture review path

• A lightweight decision record, so a lead making a system-wide call has somewhere to take it and a trail behind it
• A process fast enough that people use it voluntarily, which is the only kind that works

The engineering ladder

• What senior, lead, staff and principal mean here, and the calibration that makes a promotion decision defensible
• Closing the gap between what the org chart says and what people actually do

Compliance by design

• The technical controls our buyers require: access control and least privilege, audit logging, data retention and deletion, encryption, data residency
• How personal data — including minors' — is classified, where it lives, who can reach it, and how it moves between platforms, the shared layer and the AI products
• Evidence that exists before anyone asks for it, rather than assembled in the week before an audit
• The standards the security and infrastructure engineers work from, so a small team is sufficient

Design knowledge capture

• Getting what currently lives in people's heads into documents, starting with the parts that are about to walk out of the door

What Success Looks Like

The markers below are directional — we will calibrate specifics once you are in the seat.

In your first weeks you will produce a written map of the four platforms, the shared layer and the AI products: what talks to what, what each owns, and where it is fragile. It will be the first time this company has had one.

By ninety days, the integration contracts for the shared layer are agreed with the platform leads rather than asserted at them, a decision-record process is running and being used without being chased, and the design of our university data pipeline is captured before the people who understand it leave.

By six months, an engineering ladder exists and has been used for one review round. Security, reliability and data-protection standards are written, and a customer security questionnaire can be answered from documents rather than from two people's memory.

Over a year, the test is cheapness: integration work between platforms gets less expensive each quarter instead of more, and a new platform can be stood up against a known pattern rather than invented from scratch.

What You Bring

You have spent ten years or more building production systems, with real depth in at least one of our stacks — Rails, the data platform, or agent and LLM systems. You are senior enough that you have watched your own designs age, and honest about what you would do differently.

You have held architecture across several products at once, not one large monolith. Multi-product is the specific skill: the hard part is not designing a system, it is designing four systems that stay one system.

You have written standards that other engineers actually followed, and you can say how you got that adoption without positional authority. You know the difference between a standard and a preference, and you can tell when you are defending the second as the first.

You are comfortable being an individual contributor with influence and no reports. This is not a management role in disguise, now or later.

You write well. Clearly, briefly, and for people who are busy. Most of what you produce here is read by someone who will act on it without you in the room.

You have worked with regulated or sensitive data — education, health or finance — and you understand that compliance is an architecture problem before it is a paperwork problem. You can hold a conversation with a security auditor and with a platform lead on the same afternoon.

You have ideally taken a team through the twenty-to-fifty engineer transition, which is exactly where we are. You are comfortable in a distributed team across Delhi, Pakistan, South India and the Philippines.

Most importantly: you read this and your first reaction was not "this is a senior architecture job." It was "nobody is holding this system together and I want to be the one who does."

Why Manifest

Manifest Global is building the infrastructure for global human capital mobility, connecting students, schools, universities, and employers across 150+ countries. Our portfolio spans Cialfo (AI-powered college counseling, 2,000+ schools), BridgeU (university guidance for international schools globally), Kaaiser (trusted study abroad counseling since 1997 across India and Southeast Asia), Explore (AI-powered university outreach, 1,000+ university partners), and EduGo (study abroad counseling and student placement). Together, we move talent across borders at scale. $700B flows annually in remittances from migrant workers. 85M workers will be missing from developed economies by 2030. We're building the operating system that changes that. $76M raised. Still early.

An operating system is a claim about coherence. This is the seat that has to make it true.