A small senior team, real ownership, and software that stays in service for years
We hire rarely and carefully. When we do, we are looking for people who want to own their work from the first conversation with a client through to the server it runs on, rather than specialists who only touch one narrow layer and pass the rest along.
What working here is actually like
Fedri has been operating since 2008 and has stayed deliberately small. There is no layer of project managers translating between clients and developers, which means everyone here talks to the people who use what we build. If you find that idea uncomfortable, this is not the right place. If you find it liberating, because you have spent years building things to a specification nobody could defend, you will probably enjoy it.
The work is genuinely varied. In one week you might design a database schema, write Django views, adjust an Android screen, investigate why a query slowed down after a data import, and explain to a school administrator why a report shows what it shows. We do not separate those activities into different jobs, because the understanding gained in one improves all the others.
We take maintenance seriously, which is unusual. A meaningful share of our time goes into systems that were built years ago and are still relied on daily. That means writing code that somebody else can read, documenting decisions, and resisting clever solutions that only work while their author remembers them. People who care about craft in that specific sense do well here.
Expectations are high and communication is direct. Estimates are discussed openly. Mistakes are fixed rather than hidden, and nobody is punished for reporting one early. When something is going to be late, we tell the client before the deadline rather than on it, and that habit starts internally.
The kind of people who fit
The strongest predictor of success here has nothing to do with credentials. It is whether somebody can be handed an unfamiliar problem, work out what questions to ask, and return with something sensible without needing constant direction. Self direction matters more than any particular framework on a résumé, because frameworks can be learned in weeks and judgement takes years.
We are equally interested in people who came to software through an unconventional path. Formal computer science education is welcome but not required. This company was built by self taught work, and we recognise that capability shows up in what somebody has actually built far more reliably than in where they studied.
The one thing we cannot work around is unclear writing. Almost everything here happens in writing, including specifications, status updates, client explanations and handover notes. If you can explain a technical trade off to a business owner in three clear sentences, you are already ahead of most applicants.
What we look for
- Evidence of things you have built and shipped
- Comfort owning a task end to end
- Clear written communication in English
- Curiosity about the client business, not only the code
- Willingness to maintain software you did not write
- Honesty about what you do not know yet
Skills we use daily
How to apply
There is no application form and no automated screening. Write to us, tell us what you have built, include links if they exist, and explain what kind of work you want more of. Every message is read by a person.
info@fedri.comThe kinds of people we hire
Openings appear irregularly. We keep good applications on file and get in touch when the work matches, so writing to us is worthwhile even when nothing is advertised.
Python and Django developer
Building business applications and APIs, designing schemas, writing background tasks and being involved in the deployment of what you write. Comfortable with MySQL and interested in why a query is slow rather than only that it is.
Mobile developer
Native Android in Kotlin or native iOS in SwiftUI, consuming REST APIs, handling notifications and offline behaviour, and taking responsibility for store submissions and the ongoing maintenance that published applications require.
Infrastructure and support engineer
Linux servers, NGINX, Gunicorn, certificates, backups, monitoring and the calm handling of the occasional incident. Also front line technical support, which here means solving the problem rather than passing the ticket onward.
Interface designer who codes
Designing screens for people who use them all day, then building them in HTML and CSS. Accessibility, responsive behaviour and restraint matter more than decoration in the work we do.
AI integration engineer
Wiring language models into production systems with sensible guardrails, retrieval over client data, logging and human escalation. Healthy scepticism about what these systems can and cannot do reliably is essential.
Technical writer and trainer
Turning systems into documentation people actually read, running training sessions for non technical staff and writing the specifications that keep projects honest. A rare skill and a genuinely valued one here.
How our hiring process runs
You write to us
A short message explaining what you have built and what you want to work on is enough. We prefer a link to something real over a long list of technologies. Every message is read by a person and you will get a reply either way.
A conversation about your work
We talk through something you built, in depth. Why you structured it that way, what you would change now, what went wrong and how you found it. This tells us far more than any puzzle question ever could.
A small paid piece of real work
Where it makes sense, we ask you to complete a small genuine task and we pay for your time. Unpaid multi day exercises are not something we ask of anyone. Working together for a few hours reveals what interviews cannot.
An honest offer or an honest no
If it fits, we make an offer and explain exactly what the role involves. If it does not, we tell you why rather than disappearing. Being left without an answer is a small cruelty and we avoid it.
Introduce yourself
Tell us what you have built and what you would like to build next. Good applications are kept on file and revisited when the right work appears.