Exceptional Promise(software tengineer) - Advice Needed

Hi everyone, I would appreciate some advice on my Global Talent Visa (Exceptional Promise – Digital Technology) evidence structure.

I am a Backend Software Engineer / Technical Lead with experience since 2022. My career progression is:

  • 2022 – Semicolon Africa: Digital Native; later involved in technical facilitation/teaching.
  • 2023 – Meedl: Worked on a digital lending platform connecting students seeking education finance with investors.
  • 2024–Present – Moniepoint: Backend Engineer working on fintech/payment infrastructure.
  • 2025–Present – Down4: Technical Lead/Engineer working on a production event/social platform.

I am currently considering the following evidence:

Mandatory Criterion / Recognition

MC1 – Career Progression / Recognition: Evidence of my progression from early-career engineering into backend engineering and technical leadership.

MC2 – Invited Tech Speaking: I was invited by Semicolon Africa as a guest speaker for its “Transition to Tech” event. I have a formal appreciation letter from the CEO recognising my expertise, thought leadership and contribution to aspiring technology professionals.

MC3 – Technical Facilitation / Teaching: I previously facilitated/taught technology learners at Semicolon. I have employment/onboarding evidence and am currently gathering stronger evidence specifically confirming my teaching/facilitation activities.

Optional Criterion – Significant Technical Contribution

OC3.1 – Moniepoint / Verve Card Processing: I led the implementation of Verve card processing for Parallex Bank, expanding processing beyond Mastercard. Transaction volume subsequently increased approximately 2×. I have performance-review evidence for my contribution and am obtaining independent evidence confirming the achieved transaction increase.

OC3.2 – Moniepoint Settlement Modernisation: I modernised a settlement service from Java 17 to Java 21 and Spring Boot 2.x to 3.4.3, including reconciliation improvements, critical fixes and legacy-dependency improvements.

OC3.3 – Moniepoint Backend Performance: My manager’s assessment records sprint velocity consistently above 90% and recognises my backend/domain expertise and reliability. I am gathering monitoring/CI evidence for service availability, test coverage, release defects and engineering contributions.

Down4 – Technical Contribution / Leadership

Down4’s original product was developed externally by Rise and subsequently formally handed over to Down4. I have the actual Rise handover documentation covering the backend/server code, deployment, Expo, Apple, Google, Firebase, MongoDB, Redis, Stripe, Twilio and other infrastructure. Down4’s project documentation also identifies me as an engineer.

After the handover, I worked across the backend, mobile and web repositories and helped take/manage the product through production. My evidence includes GitHub contributions/merged PRs, Heroku and Firebase production configuration, Apple Developer configuration, a new Apple Pay Merchant ID/payment-processing certificate, and App Store production-release evidence.

Down4 reached Ready for Distribution on Apple’s App Store on 12 February 2026. Current impact evidence includes 758 registered accounts, 90 activities, 493 participants and approximately £4,063 gross activity revenue, together with App Store/Google Play acquisition evidence.

I am also obtaining a founder/CEO/CTO letter confirming my individual responsibilities following the Rise handover.

My questions are:

  1. Does my overall MC + optional-criteria structure look appropriate for Exceptional Promise?
  2. Is my Semicolon invited speaking evidence suitable for MC, or would it fit better under OC2?
  3. Is the Down4 handover → production engineering → measurable product impact evidence suitable for OC3?
  4. Should I separate Down4 into two evidence documents — one for technical handover/engineering contribution and another for production/commercial impact?
  5. Is the Moniepoint Verve implementation strong OC3 evidence if I provide independent confirmation of the 2× transaction increase?
  6. Which pieces appear weakest or incorrectly categorised?
  7. I currently have two evidence slots open. What type of evidence would strengthen the overall application rather than simply adding volume?

Thank you — I would particularly appreciate feedback on categorisation and evidence strength rather than just the number of documents.

MC is where this application is weakest. Career progression is what an assessor expects of any engineer, so it does not show recognition, and all three MC pieces trace back to one organisation you trained and worked at. The Guide sets the speaking bar for MC at high-profile sector events, which an appreciation letter from the host won’t clear. OC2 has its own bar of a sector-leading conference with 100+ attendees and a main-stage slot, and the teaching was paid work, which rules it out of OC2 entirely.

Both open slots should go to MC and come from outside that organisation, such as independent editorial coverage of your work or a talk at an established engineering conference.

The card processing piece is your strongest OC3 evidence once the 2x figure is independently confirmed, because it ties your personal work to a measurable business result. The framework upgrade and the sprint velocity piece describe good day-to-day delivery with no outcome beyond the team, so they are the weakest pieces in the pack.

Down4 works for OC3 as one document. The founder letter needs to separate what you built after the handover from what the agency delivered, with the traction numbers sitting directly under your work. Splitting it would separate the engineering from the result it produced, which weakens both halves.

Thank you so much @Akash_Joshi , will update according.

I am applying under Exceptional Promise as a Software/Backend Engineer.

Based on the feedback, I understand that my biggest weakness is currently MC, while my stronger evidence appears to be under OC3.

Proposed MC – Recognition

I will remove career progression as standalone MC evidence and will not rely heavily on my Semicolon speaking/teaching evidence for MC.

Instead, I plan to use my remaining evidence slots to find stronger independent external recognition outside Semicolon and my employers, such as industry speaking, independent media/editorial coverage, awards, competitive recognition, or similar evidence.

I am currently reviewing my previous activities to identify suitable evidence.

Question: Is this the right approach for MC, and should I avoid allocating the open evidence slots until I have genuinely strong external recognition?

Proposed OC2 – Contribution Outside My Occupation

I may have stronger evidence here that I had not included previously.

I have participated in mentoring women in technology through an external Women-in-Tech organisation (SWIT) and have also mentored through a separate startup/programme outside my employment.

Before relying on these, I am checking whether they were structured programmes, whether mentors/participants were formally selected, the duration and number of mentees, and what independent evidence is available (invitation/selection emails, programme materials, organiser letters, public posts, etc.).

Question: If these were structured, unpaid programmes outside my employment with formal mentor/participant selection, would this be a more appropriate direction for OC2 than my paid Semicolon teaching?

Proposed OC3.1 – Moniepoint / Verve Card Processing

I led the implementation of Verve card processing for Parallex Bank, extending card processing beyond the previously supported Mastercard flow.

Following implementation, transaction volume increased approximately 2×.

I currently have performance-review evidence connecting me to the implementation, and I plan to obtain independent/internal business evidence confirming the actual before/after transaction figures and resulting increase.

Question: Assuming I can independently demonstrate both my individual contribution and the 2× business impact, is this appropriately positioned as strong OC3 evidence?

Proposed OC3.2 – Down4 / Technical Ownership and Product Impact

Down4’s initial implementation was developed by an external agency, Rise, before being formally handed over to Down4.

I have:

  • the formal Rise → Down4 technical handover checklist covering backend/server code, deployment, Apple, Google, Firebase, MongoDB, Redis, Stripe, Twilio, Expo and other infrastructure;
  • project documentation identifying me as a Down4 engineer;
  • GitHub evidence showing my subsequent contributions across the backend, mobile and web repositories;
  • production infrastructure/configuration evidence;
  • Apple Developer/App Store evidence;
  • evidence of the new Apple Pay Merchant ID/payment configuration;
  • production release evidence; and
  • product adoption/commercial metrics.

Down4 reached Apple’s Ready for Distribution status on 12 February 2026.

Current product evidence includes approximately 758 registered accounts, 90 activities, 493 participants and £4,063 gross activity revenue, together with App Store and Google Play acquisition evidence.

I will also obtain a founder/CEO/CTO letter explicitly separating what Rise originally delivered from what I personally took responsibility for, developed/configured after handover, and the resulting product impact.

Following the previous advice, I now plan to present this as one OC3 evidence document, connecting:

Rise handover → my individual technical contribution → production delivery → measurable product impact

rather than separating the technical contribution and commercial results into two documents.

Question: Does this sound like the correct way to structure the Down4 OC3 evidence?

Evidence I am considering dropping

Based on the feedback, I am considering not using these as standalone evidence documents:

  • Career progression
  • Moniepoint sprint velocity/performance
  • Semicolon paid teaching
  • Java 17 → 21 / Spring Boot 2 → 3 settlement-service modernisation, unless I can demonstrate a significant measurable outcome

I would still mention relevant career/technical information in my CV, personal statement or supporting context where appropriate.

Proposed overall structure

MC – Recognition

  • Evidence still to be identified — priority is independent external recognition
  • Evidence still to be identified — priority is independent external recognition

OC2 – Contribution outside my occupation

  • Structured Women-in-Tech mentorship — subject to confirming programme structure/evidence
  • Other external structured mentorship — subject to confirming programme structure/evidence

OC3 – Significant technical contribution

  • Moniepoint — Verve card-processing implementation + independently verified 2× transaction impact
  • Down4 — post-handover technical contribution + production delivery + measurable product impact

My plan is not to start producing the final evidence documents yet. I first want to confirm that this overall MC + OC2 + OC3 direction is sensible, then I will focus on obtaining the strongest supporting evidence for each criterion.

Would you recommend proceeding with this structure? Is there anything here that is still incorrectly categorised or that you would replace before I start gathering the final evidence?

Thank you again for the guidance.

Holding the two MC slots open until you find genuinely independent recognition is the right call. MC decides this application, and the Guide asks for at least two pieces, so two strong external ones are enough. If the review of past activities turns up nothing an outsider chose to recognise you for, build that first and apply later, because strong OC3 evidence can’t carry a weak MC.

The Women-in-Tech mentoring is a far better OC2 fit than the paid teaching, as long as it clears the Guide’s mentorship bar. Beyond the structured programme with selection criteria you’re already checking for, the Guide wants a consistent track record and recognition from the programme for your personal contribution. Letters of reference alone aren’t sufficient for OC2, so pair the organiser letter with programme records or public posts naming you as a mentor.

Test the second programme hardest. Mentoring at a single startup doesn’t meet the definition, and the Guide expects mentoring to be mainly in person, which rules out online mentoring platforms.

Both OC3 pieces and the drop list look right, and one Down4 document is the correct shape. Once MC has two external pieces, this structure is ready for you to start producing the documents.

My plan is not to start producing the final evidence documents yet. I first want to confirm that this overall MC + OC2 + OC3 direction is sensible, then I will focus on obtaining the strongest supporting evidence for each criterion.

Would you recommend proceeding with this structure? Is there anything here that is still incorrectly categorised or that you would replace before I start gathering the final evidence?

Thank you again for the guidance.

@deezah I think you’re approaching this from the wrong direction.

Your narrative, the work you’ve done, and the impact you’ve made within the sector over the last five years should naturally point to the criteria that best fit your profile. It shouldn’t be a case of deciding on the criteria first and then looking for evidence to fill the gaps. That approach will be counterproductive.

Also, from my understanding, Moniepoint is primarily a fintech company focused on solving financial challenges through technology, offering services such as instant debit cards, seamless transfers, and other banking solutions. While it is a technology driven business, it is not naturally a product led company in the context typically required for OC3. OC3 is specifically focused on demonstrating your contribution within a product led company. Also, Down4 appears to be a social activity app where people in London find and join local activities. These is also not a product led company.

I would suggest starting with a narrative check first. From there, map out your existing evidence alongside any potential evidence you can realistically obtain. Once you do that, the most suitable criteria will become much clearer.

In my view, that’s a more strategic and evidence driven approach than selecting criteria upfront and then trying to make the evidence fit.

You may find this my article helpful. reason 1 to be precise

Hope this helps. All the best!

Your structure is broadly sensible, but I would focus less on the number of documents and more on whether each piece establishes recognition, individual contribution, and impact.
Career progression is useful supporting context, particularly where it shows increasing responsibility from early-career engineering into backend engineering and technical leadership. However, progression by itself is unlikely to establish recognition as a potential leader in digital technology.

I would therefore avoid presenting the progression evidence as the main basis for the mandatory criterion. The stronger point is whether you can show that your work and expertise have been recognised beyond simply being employed in progressively more senior roles.
If this was an independently invited external engagement and the CEO’s letter clearly explains why you were selected and the contribution you made, it can potentially support recognition. If it was essentially part of your employment/facilitation role, OC2 would be a more natural fit. The distinction is the context and independence of the invitation.
The handover documentation, your subsequent individual engineering work, production deployment and measurable outcomes can form a coherent OC3 case. Make the chain very clear: existing product → your specific work after handover → production outcome → measurable impact. GitHub activity alone should not be the main proof; independent confirmation of your role is important.
I would avoid splitting the same story simply to create two evidence items. If the handover, engineering contribution and resulting impact form one connected case, keeping them together can make attribution clearer and avoid repetition.
Moniepoint / 2× transaction could be useful OC3 evidence if the transaction increase is independently verifiable and the evidence establishes that your specific implementation materially contributed to it. A manager statement alone is less persuasive than combining it with system/business records showing the before-and-after figures and your role.
The settlement modernisation and sprint-velocity evidence currently sound more like evidence of technical competence/performance than significant contribution. Similarly, generic GitHub/CI metrics need context showing why the work was important to the organisation.
I would prioritise independent recognition or independently verifiable impact rather than another internal engineering task. For example, an external technical contribution, judging/mentoring activity, significant open-source contribution, invited speaking engagement, or independently verifiable product/business impact could add more breadth if you genuinely have such evidence.
Overall, focus on quality, personal attribution and external/independent validation, rather than filling all available slots. The evidence should make it easy for an assessor to distinguish what you achieved from what the wider engineering teams or companies achieved.