A twelve-person app studio ships a client release on a Friday. On Monday its best Android developer says a larger company has offered her a role. The owner offers a raise on the spot. She declines. The raise was never the issue, and the owner is left wondering what was.
Small mobile and web firms lose people in a few predictable ways. This post lists what tends to move retention and gives you a plan the owner can run without a large HR budget.
What developers say when they finally explain
In exit talks, developers in small firms seldom lead with money. They talk about work and about being heard. Four themes recur.
- The work repeats: the same client type, the same stack, no new problems.
- Priorities change with every client call, so effort is wasted.
- Nobody explains how someone grows from developer to lead.
- Pay is set by who negotiated hardest at joining, not by a visible logic.
Companies in this space have shared these concerns. The page on mobile application companies looks at the people issues typical of app teams.
Start by finding your real risk
Do not guess. List every developer and designer, then mark how hard each would be to replace in a month. Add a note on how long each has been in the company and when they last had a pay or role conversation. The names with high replacement difficulty and no recent conversation come first.
Name and role.
Main stack and client projects.
Months since last pay or role talk.
How hard to replace in a month: high, medium, low.
What the person said they want to learn.
One action this month and who owns it.A six step plan for the owner
- 1
Hold a stay conversation
Sit with each key person for thirty minutes. Ask what they enjoy, what irritates them and what would make them look elsewhere. Take notes and do not argue.
- 2
Fix the repeating pain
If late client changes cause rework, agree a change request routine with a named approver. One page is enough.
- 3
Rotate the work
Where possible, move developers between projects or let them own a technical decision. Stagnation is quieter than anger.
- 4
Show the growth path
Write down the steps from developer to senior developer to lead. State what must be shown to move.
- 5
Review pay by logic
Compare pay across people at similar scope. Explain any gap by level, skill or joining date. Correct gaps that cannot be explained.
- 6
Repeat every quarter
Retention is a rhythm. Put the stay conversations on the calendar and keep the risk sheet current.
Handle the client pull
In app and web firms, the client often holds the developer's attention. A developer who works two years on one client's product may feel more loyal to that product than to you. That can be good until the client hires them directly or the contract ends. Keep each developer's name on a second project where you can, and make sure the technical lead for each client is not a single person. This protects delivery and gives people variety.
Ask each developer which client work they enjoy and which they dread. Use the answers when you plan the next month, not as a favour but as a normal input to staffing.
Learning time is a retention tool
Developers want to stay current. A fixed block each fortnight for study, a small conference budget decided by the owner, or a rule that each person presents one learning to the team costs little. Decide the limits in writing so nobody feels favoured. The owner chooses the amount based on cash and client load.
Fair rules around releases
App releases often fall on weekends or nights. If extra hours are expected, say how they are recognised. Developers can accept hard weeks. They resent hard weeks that are never acknowledged. The post on fair rules for on-call and release night work covers this in detail.
Say the pay logic aloud
Developers talk to each other, and to friends at other firms. They will learn what others earn. Pay set by negotiation alone creates quiet resentment. Build a short sheet with levels, the skills at each level and the range you consider for each. Keep the figures with the owner and the finance head. When a developer asks about a raise, you can point to the level and the evidence needed. The decision on ranges is yours and depends on your margins.
Make the first year count
Many exits happen in the first year. A clear first week, a named buddy and a thirty, sixty and ninety day check turn a good hire into a settled one. If offers fall through before joining, read about reducing drop-off between offer and joining.
Measure what you can
- Resignations in the last twelve months, by role and by months of service.
- Stay conversations held against planned.
- Pay gaps found and corrected.
- Open positions and how long each has been open.
These counts are enough to see a pattern. They also give you facts when a client asks about team stability. For deeper support with exits and early warning signs, see employee retention and attrition management.
