What six years taught us about launching BreaktroughF1

BreaktroughF1 officially launched on 31 January 2025. But the idea took shape back in 2019, and the years in between shaped everything about how we work today.

Launch posts usually celebrate. This one is more of a field report: why we started, what the long run-up taught us, what changed once we had real clients, and what we'd tell anyone thinking of starting a technology company.

#Why we started

In conversations with business owners, the same frustration kept coming up. They were juggling separate vendors for their website, their app, their hardware and their IT support. Each vendor did their part, but nobody owned the whole picture.

When something broke between those parts (an app that didn't talk to the website, a device whose data never reached a dashboard) everyone had a reason it wasn't their problem. Projects slowed down, costs crept up, and the business owner became an unwilling project manager.

We wanted to be the partner that owns the whole picture: one team that can design the interface, write the software, build the hardware and keep it all running.

#Why it took six years

From the outside, six years of planning can look like hesitation. From the inside it felt like preparation.

We used those years to build skills across a deliberately wide range (embedded systems, web platforms, mobile apps, design and data) and to test ideas in prototypes and side projects before asking anyone to pay for them. We learned how the pieces fit together, and, just as importantly, where they usually don't.

We also learned what kind of company we wanted to be, which turned out to be the harder question.

#What the planning years taught us

#Skills compound

Every prototype, hackathon and side project added to a toolkit we now use for clients. Firmware experience makes us better at designing the apps that talk to devices. Building web platforms makes us better at designing the APIs behind mobile apps. Design work makes every engineering decision more user-focused.

The breadth only works because each skill is used for real, not just listed on a website.

#Focus beats breadth

That might sound like a contradiction after the point above, but it isn't. We cover several disciplines, and we said no to far more than we said yes to.

Within each discipline we focus on a small set of tools and practices we know deeply: a design system we trust, frameworks we've shipped many times, and processes we've refined. A clear focus on design, engineering and support made us better at each.

#Process is a product

Clients don't only buy code. They buy confidence that the project will arrive on time and work as expected. We invested early in a simple, repeatable process (discover, design, build, support) and in honest communication: weekly demos, clear scope, and early warnings when something is at risk.

#Build things of your own

Working on our own products, such as the Flutter MFA authentication plugin we're building, keeps us close to real users and real constraints. It's where we try new techniques before recommending them, and it keeps our engineering standards honest. Client platforms like RevWiki then benefit from what we learn.

#What changed after launch

#Real clients, real stakes

Prototypes forgive a lot. Production systems used by real people every day do not. Our first client platforms, such as the Findly Qatar recruitment platform and the Mentora Edu Hub brand and website, taught us more in months than some of the planning years did.

The biggest lessons were about the parts of a project that aren't in the original brief: data migration, user training, edge cases nobody mentioned, and support after launch.

#Listening beats assuming

In almost every project, the most valuable insight came from sitting with the people who'd use the product, recruiters, students, operators, and watching how they actually worked. The workflow on paper is rarely the workflow in practice.

#Small teams need senior habits

A small company can't afford rework. We adopted habits usually associated with larger teams: automated tests, code review, security checklists, accessibility checks and documentation. They feel slower on day one and save weeks by month three.

#Mistakes we made (so you don't have to)

• Underestimating "small" changes. Every extra user role or integration multiplies work. We now scope these explicitly.
• Saying yes too quickly. Some early requests didn't fit what we do best. Turning them down, and recommending someone better suited, earned more trust than stretching ourselves thin.
• Leaving our own website until last. Like many agencies, we prioritised client work over our own presence. We've since rebuilt our site with the same care we give clients.

#How we work today

Today BreaktroughF1 is a team across design, engineering, AI and security, led by co-founders Alfred Shaju (CEO) and Noeal Rajeev Thaleeparambil (CTO). We offer five services that cover the full journey of a technology product:

• AI development
• Web development and design
• Custom software and mobile apps
• IoT and hardware
• IT consulting and support

And we work across industries from education and recruitment to automotive and construction.

#Advice for anyone starting out

1. Use the waiting time well. If you can't start yet, build skills, prototypes and relationships.
2. Pick a problem, not a technology. "One accountable partner" is a problem businesses feel. "We do React" isn't.
3. Write your process down early. It's how clients learn to trust you.
4. Ship something real. Your own product, however small, teaches lessons client work can't.
5. Protect quality when you're small. Your reputation is your entire marketing budget.

#What's next

We're growing the team, expanding our open-source work and taking on more ambitious client projects, especially where AI, software and hardware meet.

If you'd like to be part of it, see our careers page. If you have a project in mind, tell us about it. We'd love to hear what you're building.