How this app developers team hires
This is the whole hiring process, written down. The six roles we take people on for, when a seat actually opens, the four stages between sending the form and hearing back, and how long each one takes. Five minutes here will tell you more than three interview rounds somewhere else.
What we hire for
The six roles this team hires for, and what each one does here
Roles open one at a time, and only when a live project needs the seat. So treat this as the shape of the app developers team rather than a list of vacancies waiting for you today.
-
Frontend developers
You build the screens people actually touch. That means clean HTML, Tailwind and plain JavaScript talking to a real API. We build for the phone first here, and we test on a normal mid range one rather than only on a fast laptop.
- JavaScript
- Tailwind CSS
- Blade & Livewire
- Core Web Vitals
-
Backend developers
You look after the Laravel and PHP side of everything we build. You would design the database before we start stacking features on top of it, write the endpoints the app talks to, and make sure the important parts have real tests around them.
- Laravel & PHP
- MySQL
- REST APIs
- Queues & jobs
-
iOS developers
You write Swift and take the app all the way through App Store review, including the privacy answers and the signing setup that hold up most first releases. We treat things like working offline and handling notifications as part of the job rather than as extras.
- Swift
- SwiftUI
- UIKit
- App Store Connect
-
Designers
You work out the flow before you draw the screens, then hand over a Figma file a developer can build from without having to guess. Components named properly, spacing that follows a scale, contrast that passes, and every state drawn rather than just the happy one.
- Figma
- Design systems
- UI & UX
- Accessibility
-
Marketers
You get the finished product in front of people. That means technical SEO and content that ranks for what buyers actually type, store listings written to convert rather than to fill a box, and landing pages you measure properly afterwards.
- SEO & content
- App Store Optimisation
- Landing pages
- Analytics
-
DevOps & testers
You make releases boring on purpose, and you catch the things the rest of us miss. On one side that is pipelines, monitoring and backups you have actually restored from. On the other it is testing on real mid range phones and writing bug reports somebody can reproduce.
- CI/CD
- Docker
- Monitoring
- QA & test plans
How we hire
Four stages, and about two weeks from the form to an answer
First you send the form on this page. It takes about four minutes, and it is the only way in. Then one person reads it — an actual person, not software — and replies within five working days. If it looks like a fit we book a call of about forty five minutes, and we mostly talk about the thing you linked. Then you get a decision within two days of that.
The timings matter as much as the stages, so here they are. Five working days to a first reply. A call within a week of that if we are going ahead. A decision within two days of the call. That is about two weeks from start to finish, and you will not be left wondering where you stand at any point in it.
The other half of the answer is when we hire, not how. A seat opens when a live project needs it, so for most applications the honest answer is not no, it is not yet. Everything you send is kept for twelve months and read again the moment that role opens up. Several people working here today applied months before there was anything for them to do. Nothing is shared with anyone else, and if you want it deleted it goes the same day you ask.
Application form
This is stage one of four. The fields marked with a star are the ones we need, the rest just help.
What working here is like
Six things you can hold us to from week one
A hiring process is only worth reading if somebody also tells you what waits at the end of it. So here are six things about working with this team.
-
You always know what done means
Every ticket says what finished looks like before you start it. If that turns out to be wrong, we rewrite the ticket instead of quietly letting it grow. Nobody gets halfway through a build here and discovers the goalposts moved on Tuesday without anyone mentioning it.
-
Everything is agreed up front
Before you start, you know what you are working on, roughly how many hours it needs and how long the project is expected to run. It is all written down rather than left as a friendly understanding, so neither of us has to remember what was said on a call six weeks ago.
-
Remote without the theatre
No screenshot software, no mouse trackers, and nobody has to leave a camera on to prove they are at their desk. Nobody on this app developers team has ever been asked to explain a quiet afternoon. We look at what you ship and how clearly you write about it. Where you sit and what hours you keep are your business.
-
We write things down instead of meeting
There is one call a week. Everything else is written, so it can wait until you are awake and thinking clearly. Writing it down also means you can search back and find out why something was decided six months ago, instead of relying on somebody remembering a call nobody recorded.
-
You are allowed to disagree
If a decision looks wrong to you, say so and explain why. Being overruled with a reason is completely normal and it happens in both directions. Being ignored is not normal, and it is the fastest way to lose good people. Pushing back has never once counted against anyone.
-
You leave with something to show
Everything we build goes out to a real store or a real business with real users, not to a demo that gets archived in three months. So you leave with work you can point at, an honest reference whenever you need one, and an introduction if we know somebody hiring.
What we look at
What earns a yes here, and what ends an application early
On the left is what moves an application forward at the call. On the right is what stops one, usually in the first few minutes of reading. None of it is about how senior you are, where you studied, or which company names are on your CV.
What earns a yes
These are the habits that make remote work pleasant instead of exhausting. You can pick up every one of them without ever having had a professional contract, which is why juniors get taken on here as often as people with ten years behind them.
-
One thing you can talk through properly
The link you send and the paragraph under it are the first things anyone reads. A small thing you built yourself, and can explain — why you did it that way, what broke, what you would change now — tells us far more than a CV listing nine frameworks. It is usually what decides whether we book the call.
-
You write clearly
Most of the work here happens in writing, so the update you send and the bug report you file shape how everyone else week goes. Writing clearly is not about big words. It is about putting things in an order that lets someone two time zones away act on it without ringing you first.
-
You ask early
The cheapest question is the one you ask before building a week of work on a wrong assumption. Ask as many as you like on the call, it counts in your favour rather than against you. Guessing quietly for five days is the only version of this that causes a real problem.
-
You think about the person using it
Someone on a three year old phone, two bars of signal, storage nearly full. If you naturally wonder what your screen does on a slow connection or with an empty list, you will fit in here quickly. That instinct is the difference between something that demos well and something that survives real people.
-
You finish things
Including the dull last bit that nobody enjoys. The error states, the empty screens, the README, the migration that has to run backwards if it needs to. Ninety percent done just means somebody else finishes it.
What ends it early
None of these make you bad at your job, and none of them are meant unkindly. They just describe ways of working that a small remote team cannot support well. Better to say so now than to find out a month in.
-
The same application sent everywhere
The generic ones are easy to spot and they get a polite no, which wastes your time more than ours. Two honest sentences about why this particular work interests you will always do better than a page of enthusiasm addressed to nobody in particular.
-
A portfolio of recoloured templates
A theme with your brand colours dropped into it is not really a portfolio piece, and it becomes obvious a few minutes into the call. One small thing you genuinely made yourself is worth more here than ten polished screenshots you cannot explain.
-
Applying on behalf of a bench
Agencies offering a pool of people who might be assigned to the work do not fit here. Whoever we talk to has to be the person who does the job, and the same person next month too. That continuity is most of what makes a small team quicker than a big one.
-
Needing the ticket written line by line
A ticket here tells you the outcome, the limits and what done looks like. It does not tell you which functions to write or which file to put them in. If you need that to get started you will find the work frustrating, and it is better to know that early.
-
Availability that changes every week
Fewer hours is completely fine, and so is a fixed window that fits around your other commitments. What does not work is a commitment that moves every week without warning, because somebody else has planned their week around what you said you would deliver.
Common questions
The rest of what people ask before applying
The hours, the contract, how junior you can be, and what happens if nothing is open when you write. If your question is not here, put it in the message field and you will get a proper answer.
-
Are you hiring right now?
Sometimes, and it honestly changes from month to month. A seat opens when a live project needs one, so rather than publish a vacancy list that would be out of date in a fortnight, the six roles are described above and the form stays open all the time.
-
What are the four stages?
You send the form. One person reads it and replies within five working days. If it looks like a fit we have a forty five minute call about the work you linked. Then you get a decision within two days of that. About two weeks in total, and no stage gets skipped or added depending on who you know.
-
Which roles does the app developers team hire for?
Frontend developers, backend developers, iOS developers, designers, marketers, and DevOps engineers or testers. Those six cover everything from the first Figma file to the release and the launch. We do not hire outside them, so an application for something else gets a polite no rather than a maybe.
-
Do I need to cover more than one of the six roles?
No, and almost nobody does. Most people are strong in one, decent in a second, and can hold a sensible conversation about a third. That is exactly what a small team needs. Pick the one you actually have, be honest about the rest, and tell us where you would like to grow.
-
How junior can I be?
Every position requires at least 3 years of relevant experience. The interview focuses on how you think, communicate, solve problems, and deliver work, but you should have a solid professional background that matches the level of the role. What does not work is claiming experience or skills you cannot demonstrate in practice, as that becomes clear very quickly.
-
How many hours a week is it?
It depends on the project, and we will not pretend otherwise. When something is active it usually runs somewhere between 15 and 30 hours a week, with quieter gaps in between. You will be told which of those you are walking into before you start, so you can plan the rest of your week around it.
-
Where do I need to be based?
Anywhere with a stable connection and a few hours of overlap with Central European Time. The team is already spread across Europe, North Africa and South Asia. The overlap is what matters, the location is not, and nobody is ever asked to relocate.
-
Can I apply by email or on LinkedIn instead?
No, the form on this page is the only way in. That is on purpose rather than bureaucracy. It asks everybody the same questions, which is the only fair way to compare people, and it means nothing gets buried in an inbox that also handles client work. Anything sent another way gets pointed back here.
-
What happens to my application if nothing is open?
One person reads it, you hear back within five working days anyway, and it is kept for twelve months and read again the moment that role opens. Several people here today applied months before there was anything for them to do. Nothing is shared with anyone else, and it is deleted the same day if you ask.
-
Can I hire your developers team instead of joining it?
Yes. Some people land here wanting to hire a developers team rather than join one, which is a different conversation. Use the contact page, tell us in a few sentences what you are building, and you will have a plan within a day. This page is only about how we hire.