This posting says what matters most is the scope you have owned, and on that measure Fauzul answers it directly: Principal Staff Software Engineer, then co-founder, then CIO, setting technical direction with the P&L attached rather than inheriting someone else's platform. He has spent nine years building enterprise products for enterprise customers, which is the half of this role most infrastructure engineers cannot claim, and he architected , the multi-tenant authorization platform built so its products would inherit one tenancy boundary instead of each rebuilding identity. He writes production Go. He is also clear about the other half: he has not run Kubernetes or Terraform in production, he has not shipped Rust, and he has never deployed a product into a customer's own cloud. Those are real, and they are the centre of this role rather than its edges, so he would rather name them on the first page than let them surface in round three.
The posting says it explicitly: what matters most is the scope you have owned, not the title. Fauzul has been Principal Staff Software Engineer, founding engineer of his own company, Engineering Manager, and CIO, across nine years in one organisation he built. He has set technical direction where being wrong cost real money, and he coached engineers into their next roles rather than only reviewing their pull requests: two of them now lead teams in Norway.
02
The enterprise half most platform engineers do not have
This role is half infrastructure and half enterprise, and the second half is nine years of his life: in Zürich for six years to acquisition, Frontgo's pod in Norway through Vipps, across 7 clinical centers, GDPR and HIPAA and VAT and WCAG 2 delivered across five portfolio platforms. Partnering directly with enterprise customers on problems that have no playbook is the job he has already been doing.
03
He builds the software that other software stands on
is a multi-tenant authorization platform built so consuming products inherit one tenancy boundary instead of each retrofitting identity; Elobooks runs on it in production. , live at wiregent.com, connects agentic payments to a double-entry, hash-chained ledger and a token economy, and certifies a company against its own record over time so the verdict shows change and growth rather than one frozen snapshot. He architected and shipped it solo. The posting says it wants engineers who enjoy building software that powers infrastructure rather than traditional DevOps backgrounds, and that is precisely the shape of his work.
The founder mindset, in six proofs
Extreme ownership, high velocity, low ego.
Lovable's own words for its culture. Each one answered with something that already happened rather than something he intends.
MF·01
Extreme ownership
He has been the person the hard call lands on.
As CIO he decided which of a founder's ideas got sequenced and which waited, with the roadmap and the P&L both his to answer for. Nobody above him absorbed a wrong call.
MF·02
High velocity
Scaffold to a working platform in eight days.
Eight days, solo, agent-led throughout, and live at wiregent.com rather than sitting in a deck. The velocity claim on this page is one you can open in a browser.
MF·03
Low ego
He says out loud which of his own products did not work.
runs, and what capped it was distribution rather than runtime, which is his own postmortem and not a rescue line. Axis, the product whose idea he still thinks was right, never shipped at all.
MF·04
Builds the foundation
Anygum was the layer the other products were meant to stand on.
One multi-tenant authorization platform, organisation-wide roles down to per-instance permissions, built so products would inherit identity rather than each retrofit it. Elobooks runs on it in production.
MF·05
Raises the bar
Mentoring measured in placements, not paper.
Two alumni now lead teams in Norway, one is pursuing graduate study in Canada on his recommendation, another moved into UX design in Germany, and an early-career direct report is now at Amazon in Sweden.
MF·06
Works with customers
Nine years inside someone else's business.
Frontgo's pod in Norway through Vipps, SkyTracks Canada with their technical CTO, in Zürich for six years to acquisition. Problems without playbooks, solved on the customer's terms.
What Lovable is looking for
Nine asks, mapped one for one. Tap "the bridge" on any ramping card.
A Staff seat defining the platform that lets enterprises run Lovable in their own cloud. Half of it is enterprise product judgement, which is nine years of his life; half is infrastructure at a depth he is honest about not having yet. Tap any "Ask Fauzul" chip to go deeper than the summary.
REQ·01Ramping
Experience architecting platform or infrastructure systems that have scaled in production
He architected , the marketplace and composition layer whose identity spine is , custom auth on Auth0, carrying organisation-wide roles down to per-instance permissions so several teams can run isolated instances of the same app under one org. It exists because was distributing SaaS across companies and did not want a new identity stack retrofitted per product; Elobooks, its multi-tenant bookkeeping SaaS, runs on it in production. Getting a tenancy boundary right once so every consumer inherits it is platform work in the sense this role means.
The bridge
The honest limit is the word production at platform scale. served 's own portfolio rather than thousands of external tenants under heavy load, and his own postmortem on it is that distribution, not runtime, is what capped its reach. The architectural reasoning transfers; the operating experience of a platform under that kind of pressure is something he would be building for the first time.
REQ·02Strong
Experience building enterprise products and working with enterprise customers
Nine years of it, and it is the half of this role most infrastructure engineers cannot claim. He carried in Zürich for over six years to 15,000+ active users and a 2026 acquisition by Loopcloud, took Frontgo's financing product through to Vipps-integrated production in Norway, and built 's HIPAA clinical platform across 7 centers. He led products into GDPR, HIPAA, VAT and WCAG 2 compliance across five portfolio platforms by treating compliance as design work rather than retrofit, which is the same instinct an enterprise deployment story needs.
REQ·03Ramping
Deep expertise across AWS, Azure, or Google Cloud
The production surface is real and current. AWS in anger across years of client work: ECS, Lambda, EventBridge, SQS/SNS, DynamoDB, MediaConvert. GCP Cloud Run behind 's Go backend, scaling to zero outside restaurant hours. Cloudflare Workers and R2 serving fauzul.com's in-browser model and 's edge-rendered site. on Cloudflare Workers plus a single always-on Fly.io machine in London holding the event stream.
The bridge
Two of the three hyperscalers this seat names, not three: he has no Azure production experience. And the depth is application deployment rather than the account-level architecture the role turns on, which is private networking, cross-cloud identity federation, and key custody inside a customer's own tenancy. He would be pairing on that side well before he owned it.
REQ·04Ramping
Experience designing distributed systems used across multiple teams
is the closest thing: one authorization and tenancy layer designed so consuming products would not reimplement login, built by two engineering pods in Dhaka and Norway who needed a shared picture of provider onboarding, org roles and instance permissions before any of it was code. Alongside it he built event-driven integrations on EventBridge and SQS/SNS, and 's double-entry, hash-chained ledger with an always-on event stream, where idempotency and ordering are correctness requirements rather than nice-to-haves.
The bridge
The consumer count is small and he will not inflate it. Elobooks is 's live consumer; Axis, the field-workforce product designed on the same boundary, never shipped. So this is a system used across a handful of teams, not an organisation of them. The design problem is the same shape at either size, but the versioning and negotiation load of many consuming teams at once is not something he has carried.
REQ·05Strong
Strong programming skills in Go, Rust, Java, C++, or similar
Go is real and shipped, not a line on a list: 's ConnectRPC backend on Cloud Run and 's agent pipeline. He has not written Rust, which is worth saying plainly rather than hiding inside the comma list this requirement offers.
REQ·06Ramping
Experience building secure, reliable systems operating under demanding production workloads
The security and reliability half is real and audited. is a HIPAA clinical platform where downtime is not an option and the audit trail is part of the product; enforces least-privilege multi-tenant RBAC; 's ledger is append-only and hash-chained so tampering is detectable rather than merely discouraged.
The bridge
The demanding-workload half is the gap. These systems are correctness-critical rather than throughput-critical, and he has not operated something under the load profile a platform serving 60 million projects implies. The discipline carries; the load does not, and he would rather draw that line himself.
REQ·07Strong
Experience operating at Staff, Principal, founding engineer, or CTO-level scope
All four, in sequence and in one place. Principal Staff Software Engineer through the IC arc to Dec 2022, co-founder from 2017, Software Engineering Manager, then CIO to 2026, deciding which ideas got built now and which got parked with both the roadmap and the numbers his to answer for. The posting asks for someone who has already operated with this level of ownership and wants to do it again; he has also felt what it costs to be wrong at that scope.
REQ·08Strong
A product mindset, caring about the people using the systems you build
Nine years of discovery sat directly with customers, plus CSPO, means he treats a platform's users as users. was blueprinted in Figma as end-to-end journeys before it was code, from registering an API to auditing which team instance a given user can reach, because an administrator's Monday morning is the thing a tenancy model is actually for. The internal-platform half of this role, building the thing that lets other engineers ship faster, is the same instinct that made him replace manual deploys with CI/CD and cut time-to-market 4x before anyone asked.
REQ·09Strong
Engineers who build software that powers infrastructure, rather than traditional DevOps backgrounds
This preference works in his favour and is worth naming. He is not a DevOps engineer and has never claimed to be. He is a product and platform builder who writes the software underneath other software: as an authorization product, 's double-entry hash-chained ledger and the token economy that runs on top of it, fauzul.com's WebGPU inference layer. The infrastructure he has built is software with users, which is the distinction this bullet is drawing.
The signature moment
He'd build this in Lovable, day one.
Ask him to build the workspace for Staff Software Engineer, Platform (Enterprise). Here is what ships first, generated the way Lovable generates everything else.
Build the day-one workspace for the Staff Software Engineer, Platform (Enterprise) seat.
Building your workspace…
Cadence board
KPI dashboard
Hiring tracker
Monday leadership syncWeekly
Ran this shape for nine years at ELO, across ten client geographies and five time zones.
Wednesday priority re-checkWeekly
The JD's own example: Monday's priority reframed by Wednesday. This is the meeting that catches it before it costs a sprint.
Leadership offsite prepQuarterly
Agenda, pre-reads, and the follow-through system that makes decisions survive contact with the week after.
All-hands draft reviewMonthly
Shaping how the CEO communicates, which is the half of this role nobody sees.
Engineering: Cycle time
Nine years of it, and it is the half of this role most infrastructure engineers cannot claim. He carried Jamahook in…
People: Headcount plan
All four, in sequence and in one place. Principal Staff Software Engineer through the IC arc to Dec 2022, co-founder…
Delivery: Compliance
This role is half infrastructure and half enterprise, and the second half is nine years of his life: Jamahook in…
Executive scorecardDesign
Set the hiring bar at ELO and held it while scaling from zero to 22 engineers.
Panel → onsite → offerRun
Ran the loop end to end, including the hard conversations at the offer and headcount stages.
Post-offer landingOwn
The part most trackers skip: whether the leader actually lands, and stays.
Not just the mockup, the habit
How I actually run agents
Claude-led for client delivery. Everything else is deliberate experiment: skills, hooks, harnesses, and loops that cut cost, tokens, and time-to-ship.
Skills from repeating patterns
When a workflow shows up more than once, I turn it into an agent skill with reusable instructions and triggers, rather than a one-off prompt.
Hooks, tools, and plugins for cost and speed
Most builds add hooks, tools, or plugins aimed at lower spend, tighter token use, and faster delivery. It is deterministic control in the places where prompts alone waste budget.
Claude ↔ Antigravity CLI for images
Recently connected Claude to Antigravity CLI (agy) so image generation rides an existing subscription, iterating taste-of-design and sharpening a design skill through that loop.
Harness and model fit per task
Claude Code for primary client build work; Antigravity and others when the task or token budget asks for it. This site's chat runs on-device Gemma 4 E2B (WebGPU + MediaPipe, model hosted on R2). NewScriber scripts with Kimi via OpenRouter and voices with Gemini TTS via Azure.
The honest ledger
Three real gaps, each with the actual bridge.
Kubernetes, Terraform, Temporal and the rest of the listed toolchain
A real ramp, not a weekend
He has not run Kubernetes or Terraform in production. His deployment experience is Docker, GitHub Actions CI/CD, Cloud Run, Cloudflare Workers, Fly.io and ECS, which is adjacent rather than equivalent, and Temporal, ClickHouse and Spanner are new names to him. He has learned production tooling under delivery pressure before, Go among them, but this is the part of the role where he would be genuinely behind a candidate who has run these systems at scale, and pretending otherwise would waste everyone's time.
Deploying a product into a customer's own cloud
The core of the role, and the newest part
Bring-your-own-cloud enterprise deployment, letting a customer run Lovable inside their own AWS, Azure or GCP account without slowing product development, is the central problem of this seat and he has not solved it before. What he has done is the multi-tenant, per-instance isolation model underneath , and nine years of meeting enterprise security reviews on the customer's terms. That is the right instinct pointed at an unfamiliar target.
Rust
Short ramp from Go
He has not shipped Rust. His systems depth is Go, plus Node.js, NestJS and Python, and the requirement names Go first among equals, so this is not disqualifying on the letter of the posting. He has picked up production languages by shipping in them rather than reading about them, Go itself and Solidity and Flutter among them.
Beyond the role
The part the checklist cannot score.
The requirements above are a fair test and he does not pass all of them. These are the reasons to have the conversation anyway.
01
He has already shipped this company's argument for a client
is a 26-year-old Dhaka export house that needed a developer for every brand change. Their site now runs a Claude-powered natural-language CMS he built: the team describes the change they want in plain English, Claude turns it into a pull request, and CI/CD ships it, so every edit stays in Git, reviewable and revertible. Non-technical owners putting changes into production without a ticket queue is the case Lovable makes about software, and he has already made it work inside someone else's business.
02
He has been the enterprise buyer's counterpart
Most platform engineers meet the enterprise security review as an obstacle relayed by a sales team. He has sat on the other side of that table for nine years, in Zürich, Oslo, Dubai, London and Montreal, and led products into GDPR, HIPAA, VAT and WCAG 2 compliance across five portfolio platforms. He knows which guarantees a buyer needs written down and which they will accept operationally, which is most of the design constraint on a bring-your-own-cloud platform.
03
Constraint is his native environment
He built a venture studio out of Dhaka delivering for clients in London, Zurich, Oslo, Dubai, Florida, Montreal and Laval, where cloud spend, timezone and hiring pool were all constraints rather than line items. runs for roughly six dollars a month. Cost-aware architecture is a habit he formed because he had to, not a principle he adopted.
04
He learns in public, daily
A 900+-day unbroken French streak with grammar explainers published to YouTube and Instagram, plus five verticals shipped zero to one across health-tech, music-tech, esports, hospitality and professional networks. The evidence that he can absorb an unfamiliar domain is not a claim about Kubernetes; it is nine years of doing it in the open where anyone can check.
05
Multilingual, multi-market, low ego about it
English fluent, Bengali native, French at A2 and climbing, Hindi verbal, and delivery experience across ten client geographies. Lovable is building from Stockholm with teams in London, Boston, New York and San Francisco. Working across cultures and timezones without needing to be the loudest voice is not a stated value here; it is just how he has worked since 2020.
Frequently asked, honestly answered
The questions an interviewer would actually ask.
The uncomfortable ones, asked properly: no Kubernetes, no Terraform, no Rust, no bring-your-own-cloud deployment. What transfers instead, and where he would genuinely be slower.
This is a platform and infrastructure role. You have never run Kubernetes or Terraform in production. Why are we talking?
Because the posting says what matters most is the scope you have owned, and I think that is the right test. I architected a multi-tenant platform our products were built to consume instead of each rebuilding identity, shipped it, and lived with those decisions for years. I have deployed across AWS, GCP, Cloudflare and Fly.io. What I have not done is operate Kubernetes or write Terraform under production pressure, and if that specific operating experience is the thing you cannot train, I am the wrong candidate and you should say so early. If what you cannot train is the enterprise judgement and the willingness to own an unsolved problem, that is the part I already have.
The core problem here is letting enterprises deploy Lovable inside their own cloud. Have you ever shipped a bring-your-own-cloud deployment?
No. That is the newest part of this role for me, and it is also the middle of it rather than the edge. The nearest thing I have built is 's per-organisation and per-instance isolation, where the tenancy boundary had to hold without every consuming product reimplementing it, and nine years of passing enterprise security reviews on customers' terms rather than my own. That gives me the instincts about what an enterprise buyer will actually demand. It does not give me the scar tissue of having shipped it across three hyperscalers, and I would be learning that in public.
Your stack is Go and TypeScript. Ours is Go, Rust, Kubernetes, Temporal, ClickHouse. How much of your first six months is just catching up?
Some of it, honestly. Go transfers directly and is genuinely mine. Rust, Temporal and ClickHouse are new. My track record on this is that I learn languages and tooling by shipping in them rather than studying them first, which is how Go, Solidity and Flutter each entered my stack, and I would want a real customer problem to do it against rather than a tutorial. But I would expect to be slower than a candidate who already runs this stack for the first quarter, and I would rather set that expectation now than miss it later.
You have been a CIO and a co-founder. Are you actually going to be happy back in an individual contributor seat?
I never left it. Through the management arc I kept writing production code, and everything I have built since stepping out of 's operating role has been solo: from scaffold to a working platform in eight days, end to end, 's front and back. The title I enjoyed most was Principal Staff Software Engineer. What I want is the hard architectural problem and the room to own it, which is what this posting is offering, and the mentoring half of the role is something I have done for nine years anyway.
What would you actually be best at in the first ninety days, given the gaps?
Talking to your enterprise customers and turning what they say into architecture, because that is the loop I have run for nine years and it is the part of this role with no established playbook. Concretely: what the security review will actually block on, which isolation guarantees a buyer needs written down versus which they will accept as operational, and where the deployment story will break a customer's own compliance posture. I would be pairing hard on the Kubernetes and Terraform side while doing it, and I would expect to be contributing to the cloud-agnostic architecture debate long before I would trust myself to own the runtime.
