Eighteen years of building software that other people depend on

The company

A small firm that behaves like a long term partner

Fedri began in 2008 with a straightforward idea. Businesses kept being sold software by people who would not be around to maintain it, and the cost of that pattern always landed on the client. A website would be built and then abandoned. An application would work well for two years and then break after a server upgrade with nobody left who understood it. We decided to build a company that did the opposite, one that treated the years after launch as the real work rather than an afterthought.

That decision shaped everything else. It is why we stayed small and senior instead of hiring quickly and delegating widely. It is why we chose technologies with long support histories rather than whatever framework was fashionable that season. It is why we insisted on writing specifications before writing code, even when clients found the extra week frustrating. And it is why a meaningful share of our revenue comes from clients who first hired us more than a decade ago.

Today Fedri delivers a full range of software and technology services. We design and build websites, we develop web based applications that run whole business processes, we write native Android and iOS applications, we design databases, we build REST APIs, we integrate artificial intelligence into existing systems, we run Linux servers, we host and maintain what we deliver, and we advise companies that simply need a clear head and a written specification before they spend money.

Our clients have ranged from single person businesses to organisations operating across several countries, and our work has been delivered in Canada, the United States and the Middle East. Some projects took three weeks. Others have been running for over ten years and are still being improved. Both kinds matter to us, and both are treated with the same care.

What we actually do all day

Stripped of the marketing language, our work is this. We listen to how a business really operates, including the parts that are messy and undocumented. We write down what a piece of software would need to do to make that work easier. We design the data structures and the screens. We write the code, usually in Python with the Django framework. We build the mobile applications where they are needed, natively in Kotlin for Android and SwiftUI for iOS. We set up the Linux server, the web server, the database, the cache and the background workers. We deploy, we test, we train your staff and we hand over documentation.

Then we stay. We watch the error logs, apply the security patches, tune the queries that only become slow once real data arrives, restore from backup on the rare occasion it is needed and add the features that experience reveals. This second phase is quieter and less impressive to talk about, but it is where the value of a software investment is either protected or lost.

Proof rather than promises

It is easy for any development company to list technologies. It is much harder to point at something large that you built, deployed and still operate. QuranRecord is our answer to that. It is a complete school management platform for Quran education used by schools, madrasas, mosques, private teachers and families in many countries, it serves more than a million page views a month, it exists on the web, on Android and on iOS, and it is provided entirely free to the schools that use it.

Every layer of QuranRecord was produced by this company, from the database schema and the Django backend to the REST API, the two native mobile applications, the notification infrastructure, the Linux servers and the support replies that go out to school administrators. When we tell a client that we can carry a system from first sketch to daily operation at scale, that platform is the evidence behind the claim.

How we price and how we communicate

We quote in stages, with each stage described in plain language and priced separately. That gives you the ability to start smaller, see something working and then decide whether to continue, rather than committing the entire budget to a document. It also makes it obvious which parts of a request are expensive, which frequently leads to a better conversation about what is genuinely needed.

Communication is deliberately direct. You will not be handed a status report full of terms designed to make the work sound difficult. If something is going to take longer than expected, you hear it as soon as we know rather than at the deadline. If a request would create a problem later, we will say so and explain the trade off, then build whatever you decide. Our job is to make sure the decision is properly informed, not to make it for you.