Integrity note — please read first
Dates on this page are an approximate founder chronology, reconstructed from memory alongside code and Git evidence where that evidence exists. Months are indicative groupings of work, not audited records, and several strands overlapped.
Nothing here should be read as a claim that Mulyba is publicly launched, legally approved, commercially live, university-approved or endorsed by any institution, or that payments are active. They are not. Mulyba is private and unpublished, its policies are pre-launch drafts awaiting legal review, and no purchase can be made.
Mulyba V2 is a rebuild and a next iteration. It is not a claim that every V1 system was directly migrated — most were deliberately not. What carried across was the product understanding, and where a V1 approach was unsafe it was replaced rather than reused.
There are no statistics, customers, awards, partnerships or investment claims on this page, because there are none to report.
Part one · Mulyba V1
Learning in public, roughly the first ten months
A Python and Streamlit application, deployed first on Streamlit Cloud and later on Railway, backed by PostgreSQL. It worked, it was demonstrated to real people, and it produced a list of hard-won constraints that the second version was built to satisfy.
Month 1 · Milestone 1
Learning Python with a real problem in front of me
Mulyba did not begin as a product plan. It began as a way to learn Python with something worth building: the repeated, exhausting work of rewriting a CV for every application. The first scripts were small and blunt — read a text file, find the sections, print them back in a tidier order.
Almost immediately the interesting problem turned out not to be formatting. It was that a CV is a claim about a person, and software that reshapes it is quietly reshaping what that person is saying about themselves.
What we learnt · The hard part was never the text handling. It was deciding what software is allowed to assert on someone's behalf — a question that ended up defining every later version.
Months 1–2 · Milestone 2
Streamlit Cloud, because shipping beat polishing
Streamlit turned a script into something a person could actually open. Deployed on Streamlit Cloud, it had a URL, a file uploader, and a form. That was enough to put it in front of someone and watch where they hesitated.
It was also the first taste of the trade-off: a framework that removes the front-end work also removes most of the control over how state, sessions and rendering behave.
What we learnt · A rough working thing that a real person can open teaches more in ten minutes than a week of design. The cost of that speed came later, and it was paid in full.
Months 2–3 · Milestone 3
Fighting the stateful prototype
Streamlit re-runs the whole script on nearly every interaction. Anything that had to survive — a parsed CV, a half-written letter, a selected vacancy — needed deliberate handling in session state, and any mistake showed up as work vanishing mid-edit.
Considerable time went into keeping a multi-step journey coherent inside a model that assumes a single pass from top to bottom.
What we learnt · A career journey is inherently stateful: import, review, choose, tailor, apply, track. If the framework does not model that, every feature pays a tax.
Months 3–4 · Milestone 4
PostgreSQL and the first accounts
Browser-only work meant losing everything on refresh, so V1 gained a PostgreSQL database and real accounts: users, saved CVs, saved letters, roles and simple policies about who could see what.
This is where the responsibility became concrete. Storing someone's employment history is not the same as storing a to-do list, and the schema had to start reflecting that.
What we learnt · The moment data persists, you are a custodian. Authentication and access rules stopped being a feature on a list and became the foundation everything else sits on.
Months 4–5 · Milestone 5
CV parsing, multiple entries, and structured cover letters
The flows that still define Mulyba took shape here: importing an existing CV, autofilling fields from it, supporting several work and education entries rather than one, and drafting a cover letter from what the person had actually recorded.
Parsing real CVs was humbling. People use tables, columns, headers, dashes, abbreviated dates and job titles that contain the word "and". A tidy heuristic that works on five documents fails on the sixth.
What we learnt · Never silently guess. An uncertain parse must be visible and correctable by the person, because the alternative is software inventing their history for them.
Months 5–6 · Milestone 6
Adzuna and the job discovery experiments
A CV without somewhere to send it is only half the problem, so V1 connected to the Adzuna UK vacancy feed and began experimenting with searching, filtering and summarising real adverts.
Duplicates across agencies, inconsistent location fields, adverts with more culture text than requirements — each pushed the design towards treating the original advert as something to preserve, not to rewrite.
What we learnt · The advert is evidence too. Keep the employer's own words intact and compare against them, rather than producing a cleaned-up paraphrase the person then applies against.
Months 6–7 · Milestone 7
AI assistance experiments, and the line that had to hold
V1 experimented with AI improvement of summaries, skills and experience wording, and with tailoring language to a specific advert. It worked well enough to be genuinely useful and, in the same breath, well enough to be genuinely dangerous.
Left unconstrained, a model will happily add a qualification, round up a date, or imply a responsibility that was never held. That is not a wording improvement; it is a false statement in a job application.
What we learnt · AI could be allowed to rephrase confirmed evidence and never to introduce new facts. That single rule became the strongest constraint carried into the rebuild.
Months 7–8 · Milestone 8
Credits, referrals and the shape of a fair model
Because model calls cost money, V1 needed a way to meter them. A credit ledger and a referral concept were built: actions consume credits, and a record explains where each one went.
The design question was fairness. Someone applying urgently for work is often exactly the person with least to spend, so anything that mattered most had to remain reachable without paying.
What we learnt · Meter the expensive external calls, never the person's own record of their life. Documents, edits and evidence should not cost anything to keep.
Months 8–9 · Milestone 9
Email verification, password recovery, and a security lesson
Real accounts need verification and recovery, so V1 grew both. Building them by hand is where the security reading became unavoidable: how passwords are stored, how reset tokens are generated, how long they live, what happens if one leaks.
Reviewing that code honestly, the conclusion was that hand-rolled credential handling written while learning is not something to run for other people.
What we learnt · Some things should not be self-built. Authentication belongs to a properly maintained managed system, and the V1 approach was explicitly marked never to be reproduced.
Months 9–10 · Milestone 10
Stripe test exploration and Railway deployment
V1 explored Stripe in test mode and moved off Streamlit Cloud onto Railway for a more controllable deployment, with environment variables, logs and a database that belonged to the project rather than to a demo tier.
Nothing was ever sold. The exercise was about understanding what a payment integration actually demands: webhooks, signature verification, idempotency, and states where money and account records disagree.
What we learnt · Payments are a correctness problem before they are a revenue feature. Building the plumbing early, with no intention of charging, meant the later architecture could be designed rather than rushed.
Month 10 · Milestone 11
Debugging on real devices, and the privacy lessons
The unglamorous months. Sessions expiring mid-form. Layouts that assumed a laptop and collapsed on a phone. Uploads failing on mobile browsers. Debug output that, on inspection, was far too close to real CV content.
Each fix narrowed what the system was allowed to log, retain or display, and mobile stopped being an afterthought — most people doing this work do it on a phone.
What we learnt · Mobile-first and minimum-necessary logging are not polish items. They are the difference between a tool people can trust with sensitive history and one they cannot.
Month 10 · Milestone 12
Showing it to people: demonstrations, a careers fair, CECOS interest
V1 was demonstrated in person, including at a careers fair, and generated interest from CECOS. Those conversations were the first outside signal that the underlying idea addressed something real.
They are recorded here as interest and conversation only. No agreement, endorsement, partnership or approval of any kind is claimed or implied.
What we learnt · Interest is encouraging and is not validation. It made the standard higher, not lower: if people might actually use this, the foundations had to be rebuilt properly.
Part two · Mulyba V2
The deliberate rebuild, roughly the final eight months
A fresh, modern, typed build with managed authentication, database-enforced isolation, evidence-grounded documents and honest commercial boundaries. Same mission, rebuilt to a standard the first version had shown was necessary.
Month 11 · Milestone 13
The decision to rebuild rather than patch
V2 is a rebuild, not a migration. The V1 systems were not lifted across; the product understanding was. What carried over was knowledge of what mattered — evidence, honesty, mobile, ownership — while the credential handling, session model and rendering approach were deliberately left behind.
The new stack is a modern typed React and TanStack application with server functions, a managed PostgreSQL backend with row-level security, and a single dark design system rather than framework defaults.
What we learnt · Rebuilding is only justified when the constraints you learnt are stronger than the code you are discarding. Here they were, and saying so plainly matters more than claiming continuity.
Months 11–12 · Milestone 14
Career Twin: evidence with a source, or it does not exist
The centrepiece of V2 is the Career Twin: a person-owned map of confirmed evidence. Anything inferred must display where it came from and must be confirmed, edited or rejected by the person before it can be used.
The Evidence Wallet extends this beyond paid employment to education, caring, volunteering and practical responsibility — valued honestly, without pretending they are equivalent.
What we learnt · Making provenance a structural requirement rather than a UI courtesy is what stops an application document drifting away from the truth.
Months 12–13 · Milestone 15
Opportunity intelligence without scoring people
Vacancies are grouped as roles to explore, with the requirements shown against confirmed evidence and the gaps stated plainly. The original advert text is preserved unchanged alongside the comparison.
There is deliberately no percentage match, no ranking and no "suitability" verdict. A number would look authoritative while carrying no defensible meaning, and it would quietly tell people what they cannot be.
What we learnt · Refusing to produce a score was harder than producing one, and it is the correct decision. Explanation is useful; an unexplained figure is not.
Months 13–14 · Milestone 16
Fast Apply, the Studio, and interview preparation
Two entry doors were kept distinct: Fast Apply for someone who needs a credible application today, and the Career Twin for deeper, slower work. Fast Apply runs as one continuous session — import, review uncertainties, keep an untouched baseline, choose a vacancy, tailor a separate version, draft an evidence-grounded letter.
Alongside it, six document templates with browser-side PDF and DOCX export, a STAR interview story builder, and a private application memory for tracking outcomes.
What we learnt · Never overwrite the baseline, always make a tailored change reviewable and reversible, and never force a long assessment on someone whose deadline is tonight.
Months 14–15 · Milestone 17
Authentication, row-level security and ownership verification
The V1 security lesson was applied without compromise. V2 uses managed authentication, and every table carrying personal work is protected by row-level security scoped to the owning account, with explicit grants and cascade behaviour.
Ownership is verified server-side on every read and write of a document, an evidence record or an application, and account deletion runs as a single atomic operation rather than a hopeful sequence of deletes.
What we learnt · Isolation has to be enforced at the database, not in the interface. A UI that hides other people's data is a presentation choice; a policy that denies it is a guarantee.
Months 15–16 · Milestone 18
Staff separation: an operational side with no route to member data
As the project grew a workspace and department structure was added for internal coordination, with access roles separated from responsibilities, hashed invitation tokens, an append-only audit trail, and a self-built browser video beta for internal calls.
The defining constraint is what it deliberately cannot do: no staff role, at any level, has a path to a member's career data. The operational side holds operational records only.
What we learnt · Internal tooling is where privacy promises usually break. Designing the boundary as an absence of capability, rather than a policy people are asked to respect, was the only version worth building.
Months 16–17 · Milestone 19
Commercial guardrails, legal drafts and a guarded Stripe test architecture
Pricing, allowances and a contributor benefit ledger were modelled and enforced server-side, and the policy set — terms, privacy, cookies, accessibility, payments, refunds — was written specifically for Mulyba rather than copied from boilerplate.
A test-mode payment architecture exists, including a signature-verifying webhook handler. It is closed. It refuses unsigned, duplicate, live-mode and mismatched events, and no payment credential exists anywhere in the project.
What we learnt · Every policy stays labelled a pre-launch draft until a solicitor has reviewed it, and nothing may imply a purchase is possible while none is. Being unfinished is fine; misleading is not.
Months 17–18 · Milestone 20
Ownership: GitHub, an owner-controlled database, and a pilot to come
The most recent work has been about long-term control rather than features. The full migration history lives in GitHub as ordered, reviewable files, and a separate owner-controlled PostgreSQL project now holds that history, applied through a GitHub-driven deployment with a read-only validator to check the result.
Preparation continues for an owner-controlled host and, after that, an invite-only pilot. The application still runs on its current managed backend; the cutover has not happened and is a separately approved step.
What we learnt · A product that cannot be moved is not really owned. Getting schema, history and hosting into the founder's hands mattered more than any feature that could have been built in the same weeks.
Part three · Owner-controlled pilot foundation
Preparing a private pilot, not a launch
The work since the last update has been about ownership and safety rather than new surface area: a schema history that can be replayed from files, invite-only access with owner approval and an audit trail, a strict split between browser-safe and server-only configuration, and tighter honesty rules in the tailoring lane. Mulyba remains private and unpublished, commercial features are inactive and no payments are taken. Where something is still being proven, it is labelled that way below.
Most recent work · Milestone 21
A source-controlled schema handoff, ordered and reviewable
The database is no longer something that exists only wherever it happens to be running. Every schema change is an ordered, timestamped migration file in the repository — thirty-four of them at the time of writing — with a matching handoff bundle kept byte-identical, so the same history can be applied to an owner-controlled project through its own Git integration rather than by hand in a console.
A repository test checks the bundle and the migration set stay in parity, because a handoff that quietly drifts from the code is worse than no handoff at all.
What we learnt · Portability is a property you have to test, not an intention you can state. If the schema cannot be replayed from files, it is not really owned.
Most recent work · Milestone 22
Private invite-only pilot access, with approval and an audit trail
Pilot access is a server-side record, not a flag in the browser. An account is pending until an owner explicitly approves it, approval can be declined or revoked, and every one of those decisions writes an audit entry naming the actor, the target, the action and the time. The owner screen shows account status and dates only — never anyone's CV, evidence or application content.
Exit routes were built alongside entry: an account can be closed and its data removed as one atomic operation, not a hopeful sequence of deletes.
What we learnt · A closed pilot is only trustworthy if leaving is as well built as joining, and if the people running it can see who has access without being able to see what those people wrote.
Most recent work · Milestone 23
Browser-safe and server-only configuration, kept apart on purpose
Configuration was separated deliberately: only publishable values reach the browser bundle, while anything sensitive is read inside server handlers at call time and never imported into client code. Server-only modules are structurally prevented from entering the browser build, so the boundary fails loudly at build time rather than quietly at runtime.
Commercial features remain inactive throughout. The payment architecture stays closed, no purchase path exists, and nothing in the pilot takes money.
What we learnt · The safest secret handling is an architecture where the secret has nowhere to leak to. Making the boundary a build error removed a whole category of mistake.
Most recent work · Milestone 24
Truthful tailoring, thin adverts, and a clearer journey
Tailoring rules were tightened and covered by tests: the imported baseline CV is never overwritten, every tailored change is reviewable and reversible, and content that cannot be traced to confirmed evidence is refused rather than smoothed over.
Adverts that arrive with only a title, employer and location are now handled honestly. Instead of implying the role has no requirements, the app states that it has limited detail, explains why a responsible tailored CV cannot be produced from that alone, links to the original advert and lets the person paste the description for that single application. Navigation between the Journey and Fast Apply lanes was refined in the same pass so the two entry doors stay distinct.
What we learnt · Refusing to produce something is a feature. A blank requirement list is a claim about the job, and software should not make claims it cannot support.
In progress — being validated · Milestone 25
Server-enforced AI allowance and pause controls (under active testing)
Because AI use has to be limited during a closed pilot, owner-controlled allowance management is being built: a global pause that blocks every AI request including the owner's, a per-account pause, and explicit small-quantity grants. Enforcement is server-side in a fixed order — signed-in, approved for the pilot, global switch, account switch, remaining allowance — with a reservation that is refunded when a request fails, so a blocked or failed attempt never consumes anything and concurrent requests cannot overspend.
This is described as being validated, not finished. It has automated coverage for grants, non-owner refusal, both pause levels, failure refunds and concurrency, and it is still being exercised end to end after a defect where a granted allowance was not reflected for the granted account. It is deliberately usage-count control only: no cost figure is shown, because the app does not meter cost accurately.
What we learnt · Report the state you can defend. A control that is still being proven belongs on the page as work in progress, not in the finished column.
Most recent work · Milestone 26
One import, many people: a CV library you can switch between and remove from
A CV can now be uploaded or pasted once and read in the browser into editable blocks — personal details, work history, education and skills — which the person reviews and confirms before anything is kept. Nothing is inferred silently and uncertain parsing is flagged rather than presented as fact.
Because an adviser, a friend or a family member may be helping someone else, more than one CV can be held at a time. Each import joins a library, the active one can be switched, and any of them can be removed. Switching or removing a CV clears every document derived from the old one, so a tailored CV or letter can never quietly carry another person's employment history. The duplicated second upload step was removed at the same time.
What we learnt · Multi-person use is normal, not an edge case. The safety work is not the upload — it is making sure derived documents cannot outlive the facts they came from.
Most recent work · Milestone 27
Tailoring that keeps the whole CV, and stops asking for the same credit twice
A tailored CV is now a complete faithful clone of the original. Every genuine section, employer, date and qualification is carried across unchanged; only the profile, skills emphasis and bullet wording are adjusted to answer the selected role. An earlier defect where sections were dropped and the target vacancy appeared as a fabricated work entry was fixed and covered by tests.
The generic wording helper no longer sits in the way as a default next step. It appears only after a real edit or an explicit request, and if the text has not meaningfully changed the request is refused before it costs anything, so nobody spends a pilot request on identical output.
What we learnt · A tailored document must be recognisably the same person's CV. And an assistant that charges for repeating itself is not helping — it is billing.
Most recent work · Milestone 28
A cover letter that belongs to the role in front of you
The letter step is now one clear action rather than a fixed skeleton. It draws on the whole confirmed CV baseline together with the selected advert and produces a complete, editable draft grounded in that person's real history. Tone can be chosen from a small set of styles; tone changes how the letter reads and never changes a claim, employer, date or achievement.
A serious defect was found in live use: after exploring several roles, the letter still addressed the first employer. The selected vacancy is now carried through the journey properly, stale drafts are cleared when the role changes, and the letter is regenerated against whichever advert and CV are actually active.
What we learnt · Working on a demonstrator is not the same as working on the screen a person is using. This one was only exposed by following a real ten-search day.
Most recent work · Milestone 29
Language a person would actually send
Internal machinery had been leaking into finished documents. Phrases such as “advert requirement” or “none supplied” could appear inside letter paragraphs, and the greeting was printed twice when a draft opened with its own salutation. Adverts too thin to support a letter are now refused before any allowance is reserved, placeholder paragraphs are discarded, and greetings and sign-offs are written once by Mulyba and stripped from body text on screen and in exports.
Honest gaps are still reported, but they are reported to the person separately — never buried inside the letter an employer would read.
What we learnt · Users judge the output, not the pipeline. A single stray internal phrase can undo the credibility of an otherwise truthful document.
Part four · Multilingual access
Understanding the journey in a more comfortable language
Britain is multicultural, and the UK employment and application journey is difficult enough to follow in a first language. This strand of work lets a person choose a support language for Mulyba’s guidance, navigation and explanations, while a CV and cover letter are still produced in English for UK applications. It is not a claim of perfect translation, of accessibility compliance, or of support for any language beyond those actually implemented; screens not yet covered say so plainly.
Most recent work · Milestone 30
Navigation that follows the chosen language
The names of the places inside Mulyba — the journey stages, the Evidence Wallet, Fast Apply, the account area — are now shown in the support language a person has chosen, in the correct reading direction for right-to-left scripts. Wayfinding words only: nothing a person has written is altered, and the wording of an employer’s advert is untouched.
What we learnt · If the menu stays in one language, the rest of the translation is decorative. People navigate before they read.
Most recent work · Milestone 31
A clearer way to choose a support language
The selector was made plainer and easier to use on a phone, with a larger touch target and a short explanation beside it: the support language changes guidance and explanations, while a CV and cover letter are produced in English for UK applications. Screens that have not yet been translated say so honestly, in the reader’s own language, rather than quietly reverting to English.
What we learnt · Saying what is not translated yet costs nothing and prevents a person assuming a gap is their misunderstanding.
Most recent work · Milestone 32
Job search that speaks the reader's language
The vacancy search screen — its fields, filters, buttons, result counts and empty states — now follows the selected language. The advert itself stays exactly as the employer published it, and a note beside it says so.
What we learnt · Translating the frame around an advert is helpful. Translating the advert without saying so would be misleading.
Most recent work · Milestone 33
Screen guidance carried across every supported language
The core guidance on the main member screens — roles to explore, the vacancy workspace, the job brief, the Application Studio, interview preparation, progress and the adviser — was written out in each supported language: English, Polish, Romanian, Arabic, Urdu, Punjabi, Hindi, Dari (Afghan Persian), Pashto and Slovak. Where a screen has not been covered yet, it carries the honest notice rather than a partial mixture.
What we learnt · Translation is product writing, not a switch. Each line had to be short enough to survive ten languages and still say the same thing.
Most recent work · Milestone 34
The dashboard follows the chosen language
The first screen after signing in — the greeting, the suggested next action and why it is suggested, the five journey stages, saved roles, closing dates and recent progress — now reads in the selected language, with the page mirrored for right-to-left scripts. Counts and dates remain in UK format.
What we learnt · The dashboard was the last screen to be wired and the first one people see. Order of work is not order of importance.
Recent work · Milestone 35
A reading draft of a job advert
Wherever an advert appears — search results, the vacancy page, the job brief and the letter step — a person whose support language is not English can ask for a reading draft in their own language. The employer’s original English wording stays above it, unchanged, and is named as the version that counts when applying.
UK terms of art, qualification names, pay figures and organisation names are deliberately kept in English and listed, and anything that could not be rendered faithfully is said plainly instead of being smoothed over. Each draft uses one assisted request, and nothing is used if no valid draft comes back.
What we learnt · A translated advert must never quietly replace the original. Understanding it and applying against it are two different acts.
Recent work · Milestone 36
A careers conversation, alongside the quick answer
The adviser now has two modes. The existing quick advice keeps its four scoped tasks and its rule that it answers only the question asked. Beside it sits a guided conversation that opens by asking what the person would like help with, then asks one question at a time about direction, preferences, constraints and the evidence already confirmed.
Suggestions are offered as interpretation to accept or reject, never as fact, and the closing summary keeps what was heard, possible directions, what still needs confirming and a suggested next step visibly apart. The conversation stays on the device for the session and changes nothing in the Career Twin.
What we learnt · People do not want a chatbot. They want to be asked sensible questions and left holding the decision.
Most recent work · Milestone 37
Interview preparation tied to a real application
Preparation now starts from tracked applications, in the order interview, then applied, then saved. With none tracked, that is said plainly rather than hidden, and preparing early for another vacancy is offered as a clearly separate, optional route. The bundle shows the original advert, confirmed evidence, and any tailored CV or letter already made in the Studio or in Fast Apply, each labelled with where it came from.
Public employer research runs only when asked for, and only from sources the search tool actually returned: if no real source comes back, nothing is stored, nothing is shown as research and nothing is charged. Generated questions are described as possible, never predicted, and each carries its category, the reason and whether it rests on the advert, the research or Mulyba’s interpretation. Questions to ask the employer can be edited or deleted, and yours are marked as yours.
What we learnt · A cited link is not evidence of research. Only the sources the tool genuinely returned may be shown as sources.
Most recent work · Milestone 38
Advice that says when your evidence has moved on
Saved advice is kept exactly as it was given, but where the evidence behind it has since changed, the answer now says so instead of quietly looking current. Where the original question can be asked again safely, there is an offer to ask it again with today’s evidence.
What we learnt · Old advice is not wrong, but it is dated. Saying so is more useful than silently presenting it as still true.
Most recent work · Milestone 39
A calmer history you control
Past conversations can be folded away or removed, and repeated versions of the same question from the same week are tidied down to the most recent one. Nothing is rewritten, and the dates stay as they were.
What we learnt · A long list is not a record. People need to be able to put their own history in order.
Most recent work · Milestone 40
A clearer CV review before anything is downloaded
The CV step now says plainly which CV is being shown and where it came from, shows the whole document rather than a fragment, and is honest that only the personal summary can be reworded. Where optional wording help is unavailable, the reason is explained and reviewing, editing, saving and downloading still work.
What we learnt · When something is unavailable, people need to know they did nothing wrong and what they can still do.
Most recent work · Milestone 41
The CV you reviewed is the CV you download
Moving from the quick lane into the Studio no longer rebuilds the document from scratch: the version already reviewed carries straight through, and can be downloaded as a PDF or Word file at the point of review. Showing a “tailored for” line on the page is a choice, off unless asked for, and it never changes a single word of the CV.
What we learnt · Continuity is trust. Seeing a different document a step later undoes the review that came before it.
Professional design foundation · Milestone 42
CV designs that look like they were made for a person
The foundation of Mulyba’s professional design system. One shared design layer now drives the screen, the PDF and the Word file, so what is on screen is what arrives with the employer. There is a gallery of designs across six families, with restrained choices of colour, typeface pairing, spacing and text size, designs you can star, and two you can compare side by side. Every design is free, and presentation never changes the wording or the evidence.
What we learnt · Design should change how a CV feels, never what it claims.
Part five · Pilot refinement and document design
Making the experience easier to read — and the documents worth keeping
Recent pilot work has concentrated on presentation quality, visual choice and comfortable reading rather than new claims. The documents gained a second, design-led way to be laid out, and the application gained a light and dark appearance choice. Evidence, wording and provenance rules are unchanged. Mulyba remains private and unpublished, its policies remain pre-launch drafts awaiting legal review, and there is no purchase path.
Recent pilot work · Milestone 43
A second document engine for design-led CVs
Alongside the professional, ATS-first collection, Mulyba now has a separate design-led Silver collection. Silver is not a prettier theme: it is a region-based page architecture, with banners, side panels, split layouts, coloured surfaces and section placement decided by the design rather than by fonts and spacing alone. Twelve original Silver designs were built across six layout architectures.
The preview and the PDF read the same resolved layout specification, so the exported document keeps the intended design, and a Silver PDF stays real selectable, searchable text rather than a picture of a page. Where a complex Silver layout cannot be reproduced faithfully in Word, the editable Word download is offered honestly as the Professional layout, built from exactly the same words. No template changes a person’s wording or evidence.
What we learnt · A visual CV needs a layout engine, not a prettier theme. The words can stay fixed while the page architecture changes completely.
Recent pilot work · Milestone 44
One interface should not force one way of seeing it
Pilot feedback showed plainly that a permanently dark interface does not suit every reader. Mulyba now has a real Light and Dark appearance choice across the application, remembered on the device, built from deliberate semantic colours for each appearance rather than a simple inversion. The CV itself stays a readable document surface whichever appearance is chosen.
Silver also gained optional profile images on the layouts that have a place for one. They are presentation only, off by default, offered as square, rounded-square or circle, and processed entirely in the browser with no AI call and no external image service. Accent and banner colours stay under the person’s control, from a curated professional palette with measured contrast.
What we learnt · Accessibility is not asking everyone to tolerate the same design. A useful interface gives people a comfortable way to read it without changing what the product says.
Recent pilot work · Milestone 45
Long careers must never fall off the page
A page architecture is only trustworthy if it holds a real working life. Each region in a Silver design keeps its own measured position on the page, so a long employment history, a dense skills panel or a lengthy personal summary continues onto a further page instead of being quietly cut short.
Continuation pages keep the design coherent rather than restarting it, and every section is placed exactly once, so nothing is duplicated and nothing is dropped when a layout changes.
What we learnt · Silently losing a line of someone's experience is worse than an imperfect page break.
Recent pilot work · Milestone 46
Proving that design cannot rewrite a person
The strongest claim Mulyba makes about documents is that appearance never touches content. That claim is now held by automated checks rather than by good intentions: the same CV is rendered through every collection and design, and the resulting words, sections and order are compared.
Further checks confirm that the screen and the export read the same resolved layout values, that older saved design choices still open safely, that professional exports are unaffected, and that a Silver PDF remains real text rather than an image.
What we learnt · A safety rule that is not tested is only a preference.
Recent pilot work · Milestone 47
Two honest collections, not a locked upgrade
The Application Studio now presents two clearly named collections: a professional, ATS-first collection and a design-led collection. Each design is shown as a real miniature of the person’s own CV with one plain line describing what it is for.
Neither collection is framed as the inferior one, ATS safety is only claimed where it is true, and during this private pilot nothing is locked, watermarked, priced or gated. Starred designs, recent designs and side-by-side comparison work across both collections.
What we learnt · People choose better when the difference is explained plainly instead of being used as a sales device.
Most recent work · Milestone 48
Changing how a document looks should never cost anything
Choosing a design, adjusting colour, typography or spacing, and downloading a CV are entirely local operations. No AI request is made, no pilot allowance is used, and no paid service is called simply to restyle or re-export a document a person already owns.
Exports are also labelled truthfully. Where the editable Word file cannot reproduce a design-led layout, it is offered as the professional layout in plain words rather than presented as an identical copy of what was seen on screen.
What we learnt · Trust is built in the small honesties: what a download really contains, and what it quietly costs.
Part six · Mulyba on a phone
Working properly on the device most people apply from
This strand is about the phone: a layout that holds at small widths, the option to add Mulyba to a Home Screen, and getting a finished CV or letter reliably onto the device. It was tested on real handsets, and what worked, what is a known limitation and what remains untested are stated separately below. Documents are still created on the device, nothing is stored for offline use, and Mulyba remains private and unpublished with no purchase path.
Recent pilot work · Milestone 49
Built for the phone people actually apply on
Most people looking for work do it on a phone, often between other responsibilities. The Application Studio was rebuilt to hold at phone width: the CV preview scales down honestly instead of being cropped, side-by-side comparison stacks one design above the other, and long role titles, version names and buttons wrap rather than pushing the page sideways.
Nothing was solved by hiding what did not fit. Each part of the screen was given a width it can genuinely live in, so no control ends up unreachable.
What we learnt · A layout that only works on a desk is not finished. Hiding an overflowing element hides the problem, not the cause.
Recent pilot work · Milestone 50
Mulyba can be added to the Home Screen
Mulyba can now be installed to a phone’s Home Screen and opened like an ordinary app, with its own icon, name and dark start screen. It is the same private application, not a separate download, and nothing is stored for offline use.
A separate irritation was also traced honestly: a sideways swipe on iPhone was the browser’s own back gesture, not a fault in Mulyba, so the horizontal step strips were made to keep their movement to themselves instead of pretending the gesture could be removed.
What we learnt · Diagnosing whose behaviour a problem belongs to matters more than patching the nearest piece of code.
Recent pilot work · Milestone 51
Getting the finished document onto the phone
Creating a CV is only half the job: the file has to reach the person’s phone. Where a browser already saves a download by itself, Mulyba lets it, with no extra tap. Where the phone genuinely supports sharing a file, it offers that. Only when an installed window can do neither does it hand the same document over as an ordinary web address with the correct file name.
Every step is decided by what the phone reports it can do, never by guessing at a make or model, and the file stays on the device throughout — held only for the moment between being created and being saved, then cleared.
What we learnt · Ask the device what it can do rather than detecting who made it. Capability survives; device guesses do not.
Recent pilot work · Milestone 52
A download should never quietly fail
Two real faults were found and fixed. A brand-new account could be checked for ownership of a document before its first save had finished on a slow connection; the save is now waited for, overlapping saves are queued, and a download stays blocked if saving fails rather than appearing to work. Repeated impatient taps can no longer start duplicate downloads.
The Studio was also asking about the wrong document: it now checks the CV a person actually has saved — their tailored version, or their untouched imported baseline — instead of an empty placeholder.
What we learnt · A silent failure is worse than a refusal. If something cannot be done yet, say so instead of showing a button that does nothing.
Recent pilot work · Milestone 53
Real phones, and the limits of what has been proven
The save-and-download journey was tested on real handsets rather than a simulator. On one Android phone it completed in both the normal browser and the installed Home Screen app. On another manufacturer’s phone the normal browser works while its installed window still refuses the handoff, so that route is stated as a known limitation with a plain way out: continue in the phone browser.
iPhone and other Android makes have not yet been tried, and that is recorded as untested rather than assumed working. A written test matrix now decides whether any further change is justified, instead of repeatedly guessing at one phone’s behaviour.
What we learnt · Say what has been proven on a real device, what is a known limitation, and what is simply untested. Those are three different statements.
Part seven · Advice that stays
Keeping the guidance a person has already paid for
The most recent strand began with a plain failure in real use: guidance created with an assisted request disappeared as soon as the page was left. Fixing it properly meant deciding what a request actually buys, how long a finished report should stay, and how the free and paid parts of the Adviser should be told apart on screen. Reports are saved to the person’s own account only, the provider’s own text is still not kept, and Mulyba remains private and unpublished.
Recent pilot work · Milestone 54
Choosing not to change working code
After the real-handset results came back, the honest choice was to stop. One phone saved documents correctly in both its browser and its installed app; another failed only inside its own installed window. That pattern pointed at one manufacturer’s app container, not at Mulyba, so no further change was made.
A test plan was written instead: try an iPhone and another Android make, record for each whether the file arrived, under what name, and whether an extra tap was needed. Any future change has to earn its place against those results.
What we learnt · Repeatedly patching one device’s quirk risks breaking the phones that already work. Evidence first, then code.
Most recent work · Milestone 55
Guidance you paid for stays yours
A real failure was found in use: a completed adviser answer only existed on the open screen. Leaving the page lost it, and returning meant spending another request for guidance already created. That was wrong on principle — a request pays for creating an answer, never for reading it again.
Every finished adviser answer is now saved to the person’s own account the moment it appears, once only, and reappears after moving around the app, refreshing, or signing back in on another day. Opening, keeping or deleting one costs nothing at all.
What we learnt · If someone has already paid to create something, losing it is a fault in the product, not an inconvenience.
Most recent work · Milestone 56
A career report worth keeping
Saved guidance is gathered in a quiet “Recent adviser reports” list, newest first, each row showing the question asked, the date, what it cost, and either the date it will be removed or that it is kept until deleted. Reports stay for twenty days by default; “Keep” removes that expiry entirely.
Opened, a report reads like a proper document rather than a chat reply: warm archival paper, ink headings, and the same four sections as before — confirmed evidence, interpretation, suggested next action, and what to confirm or improve. Two answers to the same question in the same week are both kept as separate reports.
What we learnt · Advice about someone’s working life deserves the weight of a document they can return to, not a message that scrolls away.
Most recent work · Milestone 57
One set of questions, and light mode with depth
The Adviser page had drifted: the same four questions appeared twice, once for free quick guidance and again for assisted guidance, which made the page look unfinished. There is now one set of four questions, one selected choice, and two clearly separated actions beneath it — free quick advice, or assisted guidance with its request cost stated plainly.
Light mode was also too flat, all white on white. The page now sits on a warm off-white behind raised panels with soft shadows and a restrained red tint on the chosen question. Dark mode was left exactly as it was, and the archival report keeps its own paper character.
What we learnt · Showing a choice twice does not make it clearer. Separating what is free from what is paid does.
Part eight · Mulyba town by town
One platform, local pilots run by local people
The newest strand answers a practical question: how can Mulyba be run in a particular town by somebody who lives there, without copying the app, splitting the product, or letting anyone read private career records? Towns are opened centrally, run locally on counts and dates alone, and joined only by clear agreement. Nothing here is charged for, and Mulyba remains private and unpublished.
Most recent work · Milestone 58
One Mulyba, run town by town
Mulyba is meant to be useful in a particular place — a town where somebody local already knows who needs help finding work. Rather than copying the app for each town, one new layer was added so a town such as Mulyba Walsall or Mulyba Nottingham can be opened inside the same Mulyba, with the same product and the same updates.
A town is created centrally, starts as a local pilot, and can be paused, archived or reopened at any time. Only the owner can open a town or appoint the person who runs it, and central control is never handed away.
What we learnt · Growing into new places should not mean maintaining separate copies of the same product.
Most recent work · Milestone 59
A local dashboard that cannot read anybody's life
The person running a town gets a simple dashboard for their own town alone. They can see how many people have joined, how many are taking part, how much activity there has been, and which application stages people recorded for themselves. That is all counts and dates.
They cannot see a CV, evidence, a cover letter, the jobs somebody looked at, application notes, interview answers, adviser reports, sign-in details or payment details — not even a name. Each person appears only as a reference such as Participant 7A2C, and every figure is worked out privately rather than by opening anybody ’s records.
What we learnt · A local organiser needs to know whether the pilot is working. That is a completely different thing from reading people’s private papers.
Most recent work · Milestone 60
Joining a local pilot is a decision, never an assumption
Nobody is placed in a town quietly. An invitation is created for one person, works once, and expires within days; only a one-way fingerprint of it is stored, never the code itself. Repeated attempts are limited, and a wrong or closed invitation gives the same plain “not available” answer so nothing can be probed.
Before joining, the person is shown exactly which town it is and precisely what the local organiser will and will not be able to see, and must agree. Afterwards a small line such as “Mulyba Walsall · Local pilot” appears in their account, and leaving removes that local link only — the account, CV and career record stay entirely untouched. No town is charged for anything, and no pricing exists.
What we learnt · Consent means seeing the exact town, the exact limits, and being able to walk away without losing your own work.
Part nine · Institutions and partners
One engine, two modes, and no product given away
The latest strand answers the question organisations actually ask: can a college, a charity or a council run Mulyba for the people it supports? The answer here is one shared engine with two honest modes, branded access rather than a white label, powers written down and enforced, reporting by totals alone, and joining that is always a decision. Nothing is charged for, and Mulyba remains private and unpublished.
Most recent work · Milestone 61
Institutions and partners, without cloning Mulyba
Universities, colleges and training providers ask for one thing; charities, housing associations, employability organisations, councils and employers ask for something very similar. The temptation was to build two products. Instead one shared organisation engine was built underneath, with two visible modes — Mulyba Education and Mulyba Partner — that change the wording rather than the machinery.
Education speaks about cohorts and careers staff; Partner speaks about programmes, groups and programme staff. Both run on exactly the same code, the same safeguards and the same release. There is one Mulyba, one owner and one set of updates.
What we learnt · Two audiences rarely need two products. They usually need one honest engine and two vocabularies.
Most recent work · Milestone 62
Branded access, not a white label
An organisation can put its own name, subtitle and logo on the Mulyba environment its people use. What it can never do is take the product away from Mulyba. No source code is handed over, and “Powered by Mulyba” stays visible beside the organisation’s own identity on every screen — the workspace, the invitation, and the membership card in a person’s account.
Logos are checked against the file’s own contents rather than its name, capped at two megabytes, stored privately and shown through short-lived links, so a badge can never become a way to smuggle something else into the product.
What we learnt · An organisation deserves to look like itself. It should not be able to look like the owner of somebody else’s work.
Most recent work · Milestone 63
Two very different kinds of power, written down
Central powers and local powers were separated deliberately. Mulyba alone creates an organisation, sets its registered name and mode, opens, pauses or closes it, holds every licence record and number of places, and appoints or ends the person who administers it.
An Organisation Admin looks after their own details, welcome message, logo, cohorts or programmes, invitations and the people taking part. Other staff can look and invite, and nothing more. Every one of those actions re-checks permission on the server each time, and a wrong or closed organisation gives the same plain “not available” answer to everybody.
What we learnt · Delegation only works when the boundary is enforced by the system, not remembered by a person.
Most recent work · Milestone 64
Reporting to a funder without exposing a single person
Organisations have to show their leadership or their funder that the work is happening. So Mulyba produces a simple summary — people joined, people taking part, career profiles started, CVs made, roles saved, applications recorded, interview preparation, recent activity, and the application stages people recorded for themselves — as a spreadsheet or a copyable set of figures.
Every figure is worked out privately from counts and dates. The report carries no names, no references, no list of people and nothing from anybody’s CV, evidence, chosen jobs, applications, interview answers or adviser reports, and it states plainly that no number is a claim that anybody found work.
What we learnt · Accountability can be met with totals. Reaching for individual records is a choice, not a requirement.
Most recent work · Milestone 65
Joining an organisation, and leaving it, on your terms
An organisation invitation is created for one person, works once, expires, and is stored only as a one-way fingerprint. Before joining, the person sees whose organisation it is, which group they are being placed in, and exactly what that organisation’s team will and will not be able to see. Nothing happens until they confirm.
Afterwards a branded card appears in their account with the organisation’s welcome message. Somebody can belong to more than one organisation — a college and a charity, for instance — and can leave any of them at once. Leaving ends that one link only: the account, the career profile, every CV version, letter, application, interview note and adviser report stay exactly as they were.
What we learnt · A person is not a member of a scheme. They keep their own record and lend an organisation a view of the totals.
Recent work · Milestone 66
Three layers kept apart, and nothing put on sale
Mulyba now has three separate operating layers: the internal Command Centre for Mulyba’s own work, the Local Network for town pilots, and the Organisation Network for institutions and partners. None of them shares the others’ records, and not one of them was allowed to attach itself to a person’s career tables, which remain owned by that person.
Annual licence details are recorded as intent only. There is no price, no invoice, no checkout and no payment anywhere in Mulyba. Fifty-four automated checks now guard these boundaries — including that no organisation screen can ever read career wording — and Mulyba stays private and unpublished until it is deliberately released.
What we learnt · Growth is only safe when each new layer is proven to be separate before it is trusted.
Most recent work · Milestone 67
Mistakes made undoable, and a logo chosen from the start
Testing the new layer produced exactly what real use produces: an organisation created by mistake, with no safe way to remove it. Pausing and archiving were not enough. Mulyba centrally can now delete a mistaken or test Education or Partner organisation permanently, in two deliberate steps — a plain warning listing exactly what goes and what stays, then the organisation’s exact name typed out. If anybody is still taking part or still appointed as staff, the deletion refuses and says so; nobody is ever unlinked quietly.
What is removed is the organisation and its own records only: its invitation codes, its record of actions, its staff appointments, its groups, its participant links and its logo. No account, sign-in, career profile, evidence, CV, letter, saved role, application, interview note, adviser report or payment record is touched, and no other organisation or town is affected. An organisation’s logo can now also be chosen while it is being created, through the same checked upload used afterwards. Seventy-two further automated checks guard all of this, and Mulyba remains private and unpublished.
What we learnt · A system people can safely undo their mistakes in is trusted more than one that only moves forward.
Most recent work · Milestone 68
How an account arrived, kept honestly and centrally
Deleting an organisation removes that organisation’s own records, which is right — but it also removed the only trace of how the people in it had arrived. With many colleges, charities and councils ahead, Mulyba now keeps a separate central record of arrivals that survives the deletion of any organisation: the event, the organisation’s name at the time, the date, and an honest note of whether the account already existed before the invitation was made. People appear only as short references. No name, email address, CV, evidence, letter, application, interview note, adviser report or payment detail is in it, and no member of organisation staff can reach it at all.
One Mulyba domain, one person, one account. Belonging to an establishment is a relationship, never ownership of the person. Every organisation therefore starts on the safe footing: people keep their own account, and ending an agreement ends memberships, staff access and unused invitations only. A second, contractual footing exists for accounts explicitly set up by an establishment under that arrangement — pre-launch wording, awaiting legal review — and only those accounts could ever be removed at exit. An account that already existed, an account whose origin cannot be proved, an account holding a Mulyba role, and an account still active anywhere else in Mulyba are all protected outright, and the numbers are shown before anything happens.
What we learnt · Before scale arrives, decide who owns what — and record it in a way no later deletion can quietly rewrite.
Autumn 2026 · Milestone 69
Official England apprenticeships, checked live
Mulyba now searches real apprenticeship adverts from the Department for Education’s Find an apprenticeship service in England, while Scotland, Wales and Northern Ireland send people to their own official services. The connection was checked with a live search near Leeds, which returned real adverts page by page, and each advert opened with its original wording untouched and kept apart from Mulyba’s interpretation. Checks on a phone and a desktop screen showed no sideways scrolling.
Only search details go to the official service; a person’s CV, Career Twin and personal details never do. Mulyba’s own words on these pages now follow the chosen support language in all ten languages, while the employer’s advert stays exactly as published, in English. Entry conditions are shown as things to check, never a decision about the person, and nothing is ever submitted on their behalf.
What we learnt · An integration is only finished when it has been seen working with real data, in the person's own language.
Autumn 2026 · Milestone 70
Keeping the key on the server, read at the moment of use
The apprenticeship key is now read inside each server action at the moment a search runs, never held in shared setup code. Tests confirm the key is never reachable from any page or button.
What we learnt · A secret should be read where it is used, and nowhere else.
Autumn 2026 · Milestone 71
An honest pause while the hosted preview was investigated
When the hosted preview could not see the saved key, Mulyba kept Search safely switched off rather than showing sample adverts as if they were real. The issue was reported to the platform with evidence, and no workaround was allowed to weaken the safeguard.
What we learnt · Refusing to fake a working feature protects trust more than any quick fix.
Autumn 2026 · Milestone 72
Confirmed live on Mulyba's own deployment
Mohammad confirmed the apprenticeship search working on his own Railway deployment once the key was added there, proving the same code runs unchanged across environments.
What we learnt · Owning your own deployment keeps a project moving when one host stalls.
Autumn 2026 · Milestone 73
Your apprenticeship search stays where you left it
Opening an advert or comparing one and coming back now returns the same country, filters, results, page and scroll position, whether by the Back button or a return link, without running the search again.
What we learnt · Coming back should never cost a person their place.
Autumn 2026 · Milestone 74
Scroll position measured before the tap, not after
The place in the results is now noted as the person scrolls and fixed the moment a control is pressed, so returning on a phone lands on the same advert. Edited-but-unsearched filters and paging were checked too.
What we learnt · Measure the moment a person acts, not the moment the page moves.
Most recent work · Milestone 75
Clear, honest credit for official vacancy information
Apprenticeship results and adverts now state that information comes from the Department for Education's Find an apprenticeship service, that Mulyba is independent and not endorsed by it, and link to each official listing. The privacy page explains exactly which search details are sent, and that comparisons stay within Mulyba.
What we learnt · Say plainly where information comes from and who stands behind it.
Most recent work (27 Sep 2026) · Milestone 76
International roles, a Skills Explorer and a dated UK sponsor register
Mulyba now loads real reference data into its own database: the European Commission's ESCO classification v1.2.1 in English (3,039 occupations, 13,939 skills, 126,051 essential and optional links, 619 ISCO groups) and the GOV.UK register of licensed sponsors dated 25 September 2026 (142,588 entries after exact duplicates were removed). A new Skills Explorer searches occupations and skills, and a separate International roles page reads live adverts from four employers' public Greenhouse job boards — Canonical, Datadog, Fivetran and Cloudflare — with the employer's own apply link. Sponsorship is shown as 'not stated' unless the advert itself says otherwise, and a register name match is never treated as proof of sponsorship.
What we learnt · A name on a list is a clue to check, not a fact to promise.
Most recent work (27 Sep 2026) · Milestone 77
Countries read only when an advert names them
International roles now show a country only when the location or office text names it outright, such as Ireland, UK or US. Cities no longer count, so Cambridge in Massachusetts and London in Ontario are not mistaken for Britain, Georgia stays unassigned, and Northern Ireland is counted as the UK only.
What we learnt · Many places share a name; only the country itself is evidence.
Most recent work (27 Sep 2026) · Milestone 78
Sponsorship wording read in its proper context
Mulyba now treats an advert as mentioning sponsorship only when it talks about visas or the right to work. Conference or event sponsorship is ignored, and wording such as ‘not guaranteed’, ‘cannot guarantee’ or a condition in the next sentence is shown as unclear, with the sentence quoted.
What we learnt · A word only means what its sentence means.
Most recent work (27 Sep 2026) · Milestone 79
Employer feeds that say when they are out of date
If an employer’s feed cannot be refreshed, or checks are paused because there have been too many, earlier roles are still shown but clearly marked with the time they were fetched and the reason. Downloads stop at a fixed size, and a single broken advert is skipped and counted rather than hiding a whole employer.
What we learnt · Old information is useful only when it is labelled as old.
Most recent work (27 Sep 2026) · Milestone 80
Reference data imports that cannot damage the live copy
The importer now checks an import’s real state before cleaning up after an error. A live version is never marked failed or emptied, an unreadable state is reported as uncertain, and rollback waits its turn behind any activation. Empty data, invalid IDs, blank labels and bad dates are refused.
What we learnt · When you cannot see the outcome, do nothing destructive.
Most recent work (27 Sep 2026) · Milestone 81
Skills Explorer ready for ESCO language packs
Skills Explorer can now search and display an official ESCO language pack for the same ESCO version, including occupations and their essential and optional skills. Anything missing from a pack is shown in English with a clear note. It was checked with test examples only; no language pack has been loaded yet.
What we learnt · A translation is only honest when its gaps are shown.
Most recent work (27 Sep 2026) · Milestone 82
Careful ESCO dates, credit and licence notes
The ESCO release date is now recorded as unknown, because only ‘December 2025’ could be confirmed. Credit notes treat EU-owned ESCO content as CC BY 4.0 unless otherwise indicated, flag material from third-party sources such as O*NET or Canadian classifications for separate review, exclude EU names and logos, and list Mulyba’s changes. ESCO-specific exceptions remain for the final legal review.
What we learnt · Credit the source, show your changes, and leave the legal checks to the lawyers.
Most recent work (28 Sep 2026) · Milestone 83
A richer map of occupations and skills
Skills Explorer now draws on the ESCO v1.2.1 reference collection, giving people a broader and more precise picture of the occupations and skills their work could point to.
What we learnt · Better discovery starts with better foundations.
Most recent work (28 Sep 2026) · Milestone 84
The new occupational reference data was checked before going live
The expanded occupational collection was validated end to end and activated for live use, so searches return dependable results rather than half-loaded ones.
What we learnt · Nothing goes live until it has been proven complete.
Most recent work (28 Sep 2026) · Milestone 85
Skills Explorer confirmed working on the live platform
After the data went live, Skills Explorer was re-tested on the production platform and confirmed to be working for real searches — closing the gap between a working test environment and a working product.
What we learnt · A feature is not finished until it works where people actually use it.
Most recent work (28 Sep 2026) · Milestone 86
The pilot now reaches more language communities
Live testing expanded to include people from Slovak, Polish, Urdu, Hindi, Punjabi and English-speaking communities, helping Mulyba serve people across Britain fairly whatever language they think in.
What we learnt · A British product must work for every Britain, not just one of them.
Most recent work (28 Sep 2026) · Milestone 87
More reliable account emails
Account verification and password-recovery email delivery were upgraded to handle larger pilot groups and to arrive more reliably — the quiet plumbing that decides whether someone can sign in at all.
What we learnt · The least glamorous feature is often the one people cannot do without.
Most recent work (28 Sep 2026) · Milestone 88
A readiness review of the sign-in journey
A review of signup, account verification, password recovery and the related workflows confirmed the platform is operating correctly end to end — recorded here as a checked state, not a launch promise. Mulyba remains private and unpublished.
What we learnt · Reviewing what already works is how you earn the right to build more.
Honesty about the present
What remains before public launch
Written in order. The first two steps are complete, the third is the work in hand, and the later steps stay gated behind it. None of them has a promised date, and none may be started early.
Step 1
CompletedOwner-hosted cutover
An owner-controlled host was prepared and built from the project's own GitHub repository, and the application was moved onto it as a separately approved step.
Step 2
CompletedAuthentication and pilot verification
Sign-up, confirmation, password recovery, account isolation and data deletion were exercised end to end on the new backend before any tester was invited.
Step 3
CurrentPilot safety controls
The work in hand: invite-only access by account, excluded from search engines, served away from the main domain, with plain wording on every page that this is a private beta and nothing is on sale.
Step 4
RemainingLegal review
Terms, privacy, cookies, accessibility, payments and refunds reviewed by a solicitor. Until then every policy remains labelled a pre-launch draft.
Step 5
RemainingInternal Stripe test only
After the steps above, and only in test mode, exercise the existing guarded payment architecture internally. No live key, no public checkout, no sale.
Step 6
RemainingFuture public launch
Considered only once the previous steps are genuinely complete. Until that point Mulyba is private, unpublished and free of any purchase path.
Mulyba is built in Britain by Mohammad Asif. The detail above is kept public inside the product because a service that asks people for their employment history, their caring responsibilities and their setbacks should be willing to show its own working.