Building Placement Atlas: Turning a Pharmacy Student's Problem into a 4,064-Programme Digital Platform

How I went from struggling to compare pharmacy training opportunities to independently designing, developing and launching a fully interactive web application.

It started with a problem I experienced myself

I'm a fourth-year MPharm student at University College London (UCL). During my own experience navigating the UK Foundation Pharmacist Training application process, I found myself facing a surprisingly difficult task: comparing thousands of available training programmes and working out which ones were actually right for me.

The information was there, but making meaningful comparisons wasn't straightforward.

I wanted to understand where the training sites were, whether programmes involved multiple locations, how convenient the commute would be, what the working hours and remuneration looked like, and how different opportunities compared with my own preferences.

I found myself switching between listings, researching locations independently, making notes and trying to organise everything manually.

I thought there should be a better way.

Rather than simply creating another spreadsheet, I decided to build an application that would bring the information together and make the entire decision-making process more intuitive.

That became Placement Atlas.

Explore Placement Atlas →

From an idea to a complete product

Placement Atlas has evolved into an independent web application containing 4,064 Foundation Pharmacist Training programmes across England and Wales, based on the October 2026 Oriel dataset.

I wanted it to be more than a searchable directory. The goal was to create an interconnected experience where geographical exploration, programme comparisons, personalised recommendations and shortlisting all work together.

Here are some of the features I've developed.

1. An interactive geospatial exploration experience

One of the biggest parts of the project has been building the mapping experience.

I wanted applicants to understand the geographical reality of a programme, rather than simply reading a town or hospital name.

The Explore dashboard combines an interactive map with programme listings and filtering.

Some of its capabilities include:

• Interactive programme markers across England and Wales.
• Dynamic filtering that updates the programme results and map together.
• Geographical searches and location-based preferences.
• The ability to include or exclude specific areas.
• Individual visualisations for training locations.
• Links to Google Maps for further location exploration.
• A responsive interface designed for desktop and mobile.

An especially important consideration was split and multi-site placements.

A programme might involve more than one training location, so showing a single marker would not communicate the full picture.

I developed dedicated mini-maps, navigation between training sites and location indicators to make these arrangements easier to understand.

The mapping implementation uses MapLibre GL JS and MapTiler.

Getting the map to behave properly required considerable experimentation with rendering, styling, geographical data, zoom levels, road visibility and performance. I wanted it to feel like a proper mapping application, not simply a map embedded into a website.

2. Personal Fit: recommendations that explain themselves

I didn't want applicants to have to inspect thousands of programmes individually.

This led to the development of Personal Fit.

The idea is simple: different applicants have different priorities, and a programme that looks attractive to one person might be completely unsuitable for another.

Users can establish preferences around factors such as:

• Geographical location and commuting convenience.
• Hospital, GP, community and split-placement arrangements.
• Salary and working hours.
• Individual programme characteristics and priorities.

The application uses these preferences to help identify potentially suitable programmes.

Importantly, I wanted the recommendations to be explainable.

Rather than presenting a score without context, the programme insights highlight why an opportunity might be suitable, alongside its advantages, disadvantages and trade-offs.

This makes the experience more useful than simply sorting programmes by one numerical value.

The preference and filtering systems also work together with the map and programme listings, so users can explore different scenarios without repeatedly starting from scratch.

3. Programme comparisons and an interactive simulator

Another part of the application focuses on making individual programme information easier to inspect.

I've developed an in-app programme quick-view and simulation experience that allows users to access important details directly within the application.

This includes:

• Programme type, including hospital, GP, community and split arrangements.
• Working hours.
• Published remuneration information.
• Gross and estimated net salary calculations.
• Monthly and annual pay breakdowns.

The objective is to reduce the amount of manual research required when comparing opportunities.

Instead of opening multiple listings and calculating everything separately, applicants can inspect relevant information within the same interface.

Net salary figures are estimates rather than guaranteed take-home pay, and applicants should confirm contractual and financial details with individual employers.

4. Tinder Mode: making programme discovery more interactive

This is probably one of my favourite features from a product-design perspective.

When you're dealing with thousands of opportunities, even a well-designed search interface can feel overwhelming.

I wanted to experiment with a completely different way of exploring programmes.

So I developed Tinder Mode.

It introduces a swipe-based discovery experience where users can:

• Swipe right to Like a programme.
• Swipe left to reject it.
• Super Like particularly interesting opportunities.
• Undo previous decisions and revisit programmes.

I also developed distinct visual feedback, colours and animations for each action.

The idea wasn't to turn an important career decision into a game. It was to provide an alternative way of working through a large selection of opportunities, making the discovery process more engaging and less repetitive.

The experience connects with the wider shortlisting functionality, so discovering programmes can feed into the user's personal selection process.

5. Personalised accounts and shortlisting

Placement Atlas isn't just a static information page.

I've integrated Supabase authentication, including Google sign-in, to provide an individual account experience.

Users can access their accounts and work with their own saved programme selections.

The shortlisting experience includes:

• Personalised saved programmes.
• A live shortlist count.
• The ability to remove unwanted programmes.
• Swipe-based removal on mobile.
• A consistent experience across the different application sections.

This was important because I wanted users to be able to return to their research rather than lose track of the programmes they had previously explored.

6. Product design and the details behind the interface

A substantial amount of development time has gone into the overall user experience.

I wanted Placement Atlas to feel like a coherent, independent product rather than an academic project assembled from unrelated components.

Some of the design and UX decisions include:

• An editorial-inspired ivory and burgundy visual identity.
• Light and dark themes.
• Responsive layouts for different screen sizes.
• Consistent programme cards and information hierarchy.
• Interactive navigation and filtering.
• Custom map controls and visual styling.
• Animated interactions and feedback.
• Dedicated experiences for exploration, comparison, personalisation and discovery.

I've also spent time refining smaller interactions, such as undo animations, shortlist removal, map navigation and the way programme information is presented.

These details matter because a product can have extensive functionality and still be frustrating to use if the individual interactions don't work together.

7. The technical development

This project has taken me into several areas of software and product development that I hadn't previously worked with at this level.

The technologies and areas involved include:

One of the more challenging aspects has been integrating all these components into one consistent application.

For example, the map isn't an isolated visualisation. It needs to respond to the same filters and preferences as the programme listings. The programme cards need to communicate the right information, and the shortlist and discovery experiences need to work consistently across the application.

This requires thinking about how the entire product behaves, not just whether an individual feature works in isolation.

8. Building outside my degree subject

Perhaps the most interesting part of this experience is that I'm studying pharmacy, not computer science.

I didn't start with a conventional software engineering background or a complete technical blueprint.

I had a problem I wanted to solve, an idea of what the experience should look like, and a willingness to learn what was necessary to build it.

I've used AI-assisted development tools throughout the process. They've helped accelerate experimentation, implementation and troubleshooting, but they've also made it important to understand what is actually happening beneath the interface.

I've had to make product decisions, work through technical problems, integrate different systems, investigate unexpected behaviour and repeatedly test and refine the application.

One thing I've learned is that building a product involves much more than generating code.

You need to understand the user, identify what matters, prioritise features, make trade-offs, think about architecture and ensure that the entire experience works together.

AI can make development more accessible, but having a clear product vision and being able to evaluate, debug and improve what you're building remain essential.

9. What's next?

Placement Atlas is now live, but I don't consider development finished.

There are still opportunities to improve the quality and completeness of programme information, refine the mapping experience, expand the decision-support functionality and understand how applicants actually use the platform.

I'm particularly interested in gathering feedback from:

• Current MPharm students preparing for foundation training.
• Applicants who have already completed the Oriel process.
• Current foundation trainee pharmacists.
• Developers and product designers interested in the application itself.

I'm also exploring the wider entrepreneurial possibilities of building independent digital products, including user research, partnerships and sustainable business models.

For now, my priority is to make Placement Atlas genuinely useful to the people it was built for.

Try it yourself

Website: https://placementatlas.co.uk

I'd genuinely appreciate feedback, particularly on the mapping experience, Personal Fit recommendations, programme comparisons and Tinder Mode.

If you've built something similar, work in product development, or have experience with geospatial applications, I'd also love to hear your thoughts.

What would you improve first if you were developing this product?

Placement Atlas is an independent student-developed project and is not affiliated with NHS England, Oriel, the General Pharmaceutical Council, the Royal College of Pharmacy or any training provider. Programme information is based on the October 2026 Oriel dataset. Information may change, so applicants should verify current details with official sources and individual training providers before making application decisions.

Built by Phivos Michailides | UCL MPharm | Product Builder & Healthcare Technology Enthusiast