Hubflo case study
Helping Hubflo evolve from a French all-in-one MVP into an international client portal platform
I joined before launch and stayed through a startup pivot, leading a sensitive multi-currency migration and building reusable Rails systems for file viewing and mobile access.
- with Hubflo
- 4+ years
- Joined before the first users
- Pre-launch
- clients
- 2,200+
- businesses, clients and contractors collaborating through the platform
- 20k+
- Company
- Hubflo — a B2B SaaS that began as an all-in-one management platform for French independent professionals and very small businesses, then pivoted into a client portal platform for service businesses.
- Role
- Senior Ruby on Rails Product Engineer
- Engagement
- July 2022–August 2026
- Stage
- Pre-launch MVPstartup pivotinternational B2B SaaS
- Team context
- Fourth engineer to join
Joining before the first users, and staying through a startup pivot
Hubflo was about six months old when I joined in July 2022. I was the fourth engineer on the team. We were still building the MVP, and the first users hadn’t come on board yet.
The original product was a French-language all-in-one platform for independent professionals and small businesses in France. Over the following four years, Hubflo launched, grew and pivoted towards client portals: branded spaces where service businesses could collaborate with their own clients through files, messages, tasks, forms, billing and other workflows.
A pivot isn’t a clean restart. Existing users, data and workflows still matter while priorities and the product architecture change around them. Working through that transition meant adapting a live SaaS to a new direction without pretending everything already built was disposable.
“He never took a ticket at face value. He’d ask why we were building something, push back when it didn’t make sense, and often came up with a better angle than the one we started with.”
Product ownership, not ticket execution
I worked directly with Hubflo’s CTO, product team and customer-facing team. Some needs arrived incomplete, so I clarified them with the team and challenged solutions that added unnecessary complexity. I made product and architecture decisions, developed features end to end, and stayed responsible through rollout and stabilisation.
Selected work
Putting that ownership into practice
Three projects that show how I approach broad, ambiguous or especially sensitive product and engineering problems.
1. Turning a euro-only financial model into an international foundation
Hubflo was built for the French market, so its financial workflows assumed euros. Once the company started expanding internationally, that early assumption affected the whole product.
“Over our 4 years working together, I’ve especially appreciated his autonomy and his ability to scope and deliver complex projects.”
The business change
Adding another currency touched far more than the displayed symbol. Amounts existed throughout quotes, invoices, payment schedules, catalogue items, projects, budgets, costs, margins, expenses, dashboards, exports and integrations. The way money was stored, calculated, displayed and transmitted had to become consistently currency-aware.
Why the migration was high-risk
Hubflo was already in production with real financial data. A migration bug could have silently changed totals in invoices, exports, or the financial and accounting reports customers relied on. A silent mismatch could have caused serious problems for users and damaged their trust in the product.
A single large rewrite would have been hard to verify or reverse, and the application had to stay fully available throughout the project.
How I led it
I led the project from scoping to completion and implemented the large majority of the migration. Other engineers contributed to specific areas, but I defined and drove the overall strategy.
I mapped the affected workflows, strengthened regression coverage and split the migration into small stages I could verify. We introduced the new currency-aware representation alongside existing data and kept both in sync during the transition. Then we backfilled and checked existing records, switched each financial area independently, and removed the legacy structures once the new path had proved reliable.
Currency and localisation stayed separate. An organisation could operate in its reference currency while each user still saw amounts formatted for their language and locale.
The scope was deliberately limited: remove the euro-only assumption safely and make financial data consistently currency-aware.
The result
Hubflo gained the multi-currency capabilities it needed to expand internationally. The full migration reached production without user-visible downtime, regressions, data loss or production bugs. Existing euro-denominated values remained unchanged while the system became currency-aware, and new organisations could select their currency at signup.
- No visible downtime.
- No regressions.
- No data loss.
2. Building one reusable file viewer without adding frontend complexity
The product problem
Files appeared throughout Hubflo, but viewing them was fragmented. Depending on the screen, a click could open the asset in a new tab or trigger a different action. Hubflo needed one consistent way to view images, PDFs, video and audio across the main application and its client portals.
Displaying a file in a modal was straightforward (even centring it, for once). The real question was when a meaningful gallery existed. A project, folder or conversation can define a reliable set of files and a meaningful order. A filtered or aggregated view may not. Instead of reconstructing a fragile “previous” and “next” sequence inside the viewer, I designed two modes:
- A contextual gallery when the surrounding product area can provide a trustworthy scope and order.
- A simple viewer when it cannot.
The product domain defines the gallery. The viewer handles presentation and navigation. This keeps business rules out of the viewing layer and avoids maintaining the same logic twice.
“That mix of strong engineering and genuine product thinking made him a true partner, not just an executor.”
A deliberately simple Rails architecture
I built the viewer with Rails and Turbo, avoiding both a dedicated JavaScript viewer dependency and a custom client-side implementation. This kept the feature close to the existing application and easier for the team to maintain. Stimulus is used only for keyboard navigation.
Each supported media type has a small server-rendered partial, selected by a helper according to the file’s MIME type. Adding another format therefore requires one renderer and one mapping rather than changes throughout the viewer.
The viewer reuses Hubflo’s existing authorisation boundaries. It relies on native browser capabilities where they are dependable, then falls back to a download when a format cannot be displayed safely.
The result
Hubflo gained one secure viewing experience shared across the main application and client portals. The same viewer was later reused for files added through other product features, keeping the implementation centralised and easy to extend.
3. Adapting the Rails client portals for mobile apps
The product problem
As client portals became central to Hubflo’s direction, customers needed a good way to use them on mobile.
On the web, the domain being visited identifies the relevant customer environment before a contact signs in. The shared app had no customer domain to start from, so it didn’t know which portal to load. Plus, the same email address could also be associated with several organisations.
Oh, and simply asking for an email address and displaying the related portals would also reveal private business relationships to anyone entering somebody else’s address.
Building a secure entry flow for the shared app
I packaged the existing Rails application inside native shells for iOS and Android. The product itself still ran in Rails, while the shells made it installable and connected it to native features. This meant Hubflo didn’t have to build and maintain separate native codebases from scratch, saving a lot of time and money.
There was no documentation for this particular multi-tenant use case, so I had to do a lot of research and work out the approach myself.
The shared app required a secure way to direct users to the right customer environment, including people connected to several organisations. I designed and delivered an entry experience that handled those cases while preserving Hubflo’s existing access controls.
I then connected the Rails application to its native shell for app links, push notifications, device registration, badges and deep links to relevant content.
Reusing the same approach for white-label apps
The same setup supported a shared client portal app and branded shells that opened directly into a customer’s portal. The shared app reached production first. The wider team then reused its Rails-side authentication, navigation and notification work for the branded apps.
As of August 2026, Hubflo had 15 client portal apps available on both iOS and Android: one shared app and 14 branded apps.
- Client portal apps
- 15
- Shared app
- 1
- Branded apps
- 14
- Platforms
- iOS + Android
“Robin is the kind of developer you can rely on with complete confidence.”
Reliability on sensitive work
Security was part of my day-to-day product engineering work at Hubflo. Working with the CTO, I contributed to application-security work for Hubflo’s Google Cloud Application Security Assessment, alongside technical controls supporting its broader security and compliance requirements.
- Google Cloud Application Security Assessment
- SOC 2— Security & operational controls.
- HIPAA — Healthcare data safeguards.
My contributions included a strict Content Security Policy with nonces and Subresource Integrity, stronger account protection through lockouts, password requirements and configurable two-factor authentication, and secure ZIP-import handling.
As with the projects above, I matched the safeguards to the actual risk and tested dangerous cases explicitly. I left the team with controls it could maintain.
Adapting without adding unnecessary complexity
Across these projects, I did the same kind of work: clarify what was at stake, make the trade-offs visible, and take the work through production in a form the team could maintain.
That mattered during the pivot, when the new direction still had to coexist with existing users, data and workflows.
The work took different forms. I replaced an early euro-only assumption while keeping existing financial data intact. The file viewer stayed within Rails and Turbo. For mobile, the Rails application ran inside native shells, with a custom authentication flow for the shared app and links to native features.
My preference is simple: build the smallest system that handles the product problem and its risks, then leave something another engineer can understand after I’m gone.
- End-to-end ownership
- Product judgement
- Startup adaptability
- Safe migrations
- Rails-first simplicity
- Security-conscious delivery
Need senior Rails product engineering capacity?
I work remotely with founder-led and small B2B SaaS teams that need senior product and technical capacity without adding a full-time hire or turning every problem into a detailed specification first.
I am particularly useful when a team needs someone to take ownership of a complex feature, migration or product area from initial framing through production.