Principal author where I owned the surface, useful contributor elsewhere, and clear about which is which.

The team was small and distributed, and it worked because of who was in it. Albert Robescu, ReadyFly's founder and CEO, wrote the product's positioning and its briefs, kept a distributed team in sync, and carried ReadyFly out into the ecosystem with a founder's genuine passion. Priya built Maya's intelligence — the AI matching and the agent engine — and is the API's principal author; Talib built the API's authentication and CV-parsing services and owned the CI/CD pipeline. The cleanest way to draw my boundary with Priya's work: Maya's mind is hers; Maya's face is mine.

At a glance

  • Company — readyfly.io. London-registered, distributed team. Part-time, equity-based.
  • Product — Maya, an AI career agent. Candidates don't apply; Maya represents them and brings interview invites. Behind it sits a dual-agent network: a career agent on the candidate's side, a hiring agent on the company's, matching instantly.
  • Web application — 157 of 209 commits are mine, and I made the first commit to the repository. That is the substance behind "founding frontend engineer": not a title, a repository that started with me.
  • My surfaces — Maya's candidate experience (conversational onboarding, job-pitch review), the public landing and its live dual-agent demo, the consent layer, and the earlier hiring-platform MVP including its live interview surface.
  • API — 31 of 209 commits, roughly 15%.
  • Stack — Next.js 15 with TypeScript and Redux Toolkit on the web; Python and FastAPI on the API.

Commit counts are self-counted in private repositories belonging to the company; no source code is shared here. They measure my share, not the team's worth.

The product problem

Applying for jobs is the broken part of hiring. Good engineers — especially the passive ones every company says it wants — will not spend evenings writing applications, and the candidates with the most options are precisely the ones who apply least. ReadyFly's answer is to invert the direction: you don't apply; you get interview invites. Maya learns who a candidate is, keeps a live profile, and pitches them privately to roles they would actually take, while a hiring agent on the company side analyses roles and surfaces interview-ready engineers with the fit explained. The two agents match; the candidate approves or declines.

That thesis puts unusual weight on the frontend. A product that says "hand your job search to an agent" is asking for more trust than a job board ever needs, and the interface is where that trust is earned or lost: the inversion has to be understood in seconds, every invite has to arrive with enough context that approving it feels informed rather than hopeful, and nothing can feel like noise — zero noise is the product's core promise.

What I owned, and where the lines ran

What I owned

  • The web application, as principal author — from the repository's first commit: Maya's candidate experience, the public landing, authentication, interview scheduling, messaging, notifications, company and job management, role-based dashboards for candidates, recruiters, companies and administrators, and progressive web app support.
  • Maya's face — the conversational onboarding and the job-pitch review experience through which candidates meet their agent, teach it who they are, and answer what it brings back.
  • The public landing and its live demo — the page readyfly.io serves today, including the seven-state dual-agent demonstration at its centre.
  • Consent enforcement — the GDPR and ePrivacy remediation described below.
  • Front-end performance decisions, including how the real-time media library is loaded.

What I contributed to

  • The Python/FastAPI API — services, API surface, domain models, routing, utilities and the security layer. The substantive piece was implementing the microservice decomposition that separated CV ingestion, authentication and profile services out of the monolith. I also added WebSocket support and worked on the behaviours of Maya, the conversational assistant.

The line with Priya's work is the one the opening drew: the platform's matching quality is hers, not mine. Where I own the agent layer myself, end to end, is LILA.

Maya's face

A candidate's first real interaction with Maya is teaching it who they are, and I built that as a conversation rather than a form: an onboarding flow where the profile assembles itself alongside the chat, so the candidate watches Maya understand them in real time. The same split-view pattern carries through the product — the conversation on one side, the artefact it produces on the other.

The other half of the candidate experience is the job pitch. When the agents match, the candidate receives not a listing but a case: a match score, the reasoning behind it, compensation set against their stated expectations, the growth path, and the company's context. I built that review surface, and the design bar for it was set by the product's own promise — if approving an interview is to feel informed rather than hopeful, the pitch card has to carry the entire argument on its own.

Selling the inversion

A landing page for an inversion has a specific problem: the value proposition contradicts the visitor's habits, and explaining that in paragraphs loses them. The working principle from the product brief was claim → show → minimal confirmation, and the centre of the page is a live seven-state demonstration I built: a role is posted, both agents activate and match, the candidate is selected, the invitation lands in an inbox, the pitch is reviewed, the interview is confirmed — playing as an autonomous loop with no explanatory text above it, because the demo has to carry the understanding. I implemented both the candidate and the recruiter views of that page.

It is what readyfly.io serves today, which makes it the one part of this work anyone can inspect without my access.

External monitoring found sixteen non-essential cookies loading before consent, a vendor loading without it, and a possible data transfer outside the UK and EU. The remediation brief's central point was that this is not a legal-documentation problem but a technical-enforcement one: nothing non-essential may execute before explicit consent. I implemented that enforcement — consent-gated script loading, the cookie banner and settings surface, and the policy pages behind them — deliberately without a paid consent-management platform, because the budget for one was zero. The consent banner on readyfly.io is that work.

The earlier chapter: the hiring-platform MVP

Maya is where the product settled; it is not where it started. The first stretch of the tenure built a four-audience hiring platform — candidates, recruiters, companies, administrators — whose most demanding surface was a live technical interview: real-time video over LiveKit, an embedded Monaco editor and proctoring, running concurrently in one browser tab, under conditions where a stutter is a candidate losing their place in a problem while a recruiter watches. Making three subsystems that each want the main thread coexist — lazy loading, separate initialisation, heavy work kept off the interaction path — remains some of the most demanding front-end engineering I have done, and one decision from it is worth keeping on the record: I split the WebRTC library into an asynchronous chunk so its cost falls on interview sessions rather than on every page view.

The MVP's live interview session — three concurrent subsystems in one browser tab, with the ownership boundary at the bottom, where the models live.

The CV flow from that period parsed uploads in the browser through pdf.js, so a candidate gets immediate confirmation on the document they just chose. The honest caveats stand: I argued for it on completion-rate grounds I did not measure, and on a slow device it is a slow parse with no server fallback — that would be the first change I made.

What is measured, and how

Only the ownership figures are measured here, and they are commit counts rather than surviving-code analysis:

  • Web application — 157 of 209 commits, roughly 75%, plus the first commit in the repository.
  • API — 31 of 209 commits, roughly 15%.
  • Maya's candidate surfaces — where this page says Maya's face is mine, that summarises commit counts on the product's Maya sections, measured on both the main and the development branch with the weaker taken, attributing the substantial majority to me. The per-area numbers stay in my private records, for the same reasons as on the Cendra page.
  • The landing and the consent work — attributable by commit history, and unusually for private employed work, publicly inspectable: readyfly.io serves the landing and the consent banner described above. That makes them the only claims on this page a reader can check without my access.

Commit share is the weakest of the ownership measurements — it counts activity rather than what survived — and for a part-time engagement it is the measurement that was available to me. Where I have been able to measure surviving authorship by blame, I have: that is on the Cendra page, with the method written out.

No source code is shared, and there are no product metrics on this page. Whatever the platform achieves commercially is the company's to report, not mine.

Limitations, and what I would change

  • I have no before-and-after numbers for the performance work. Splitting the media library into an async chunk was a judgement call about where cost should fall, argued from library size rather than from measured bundle and load figures. I would instrument it now — that is exactly the kind of change that is easy to justify and easy to be wrong about.
  • Client-side parsing has a floor. On a low-end device it can be slower than a server round-trip would have been, and the flow as I built it has no fallback that hands the work back to the server when the client is struggling.
  • Commit share proves less than it looks like it proves. 157 of 209 says I wrote most of the repository. It does not say how much of that code is still there, and I cannot run blame against repositories I no longer have access to.
  • Part-time depth is uneven. Maya's candidate experience, the landing and the interview surface got the attention they needed; coverage elsewhere in the application is thinner, and a full-time engineer would not have made the same allocation.
  • Proctoring, as I built it, is a product surface rather than a guarantee. I would not describe it as a security control, and I would want anyone relying on it to know the difference.
  • The landing demo's numbers are illustrative. The company names and match scores in the seven-state demonstration are product copy, not measurements. I built the demo; I do not vouch for its figures as data.