title: "" description: "A case study on turning TecleTaxi Corporativo from a product concept into a commercial B2B mobility platform—and the technical, organizational, and business lessons learned along the way." date: 2026-07-24 slug: "building-scaling-b2b-mobility-platform" category: "Technology Strategy" tags:

product-engineering
entrepreneurship
b2b-platform
mobility
fintech
cloud-architecture
engineering-leadership
product-strategy
team-scaling
digital-transformation draft: false

From Concept to Commercialization: Building and Scaling a B2B Mobility Platform

A case study on product development, cloud architecture, fundraising, organizational growth, and the difficult work of turning an idea into an operating business.

Some products begin with a new technology.

TecleTaxi Corporativo began with a gap.

Companies needed a better way to manage employee transportation, service providers, authorized rides, payments, reporting, and operational control.

Consumer mobility applications were becoming increasingly visible, but corporate transportation involved a different set of requirements.

A company did not simply need to request a vehicle.

It needed to know:

Who was authorized to use the service
Which department or cost center should be charged
Whether the trip complied with corporate policies
How payments would be processed
Which records were required for reconciliation
How the service would be monitored
Who would respond when something went wrong
How multiple suppliers and transportation providers could be coordinated

This was the context in which TecleTaxi Corporativo was conceived.

The goal was to create a B2B mobility platform that combined transportation, payment, corporate controls, and operational visibility.

Building the software was difficult.

Building the company around it was harder.

Identifying the Real Product

The first version of a product idea is usually expressed through features.

In our case, those features included:

Ride requests
Driver and vehicle location
User authentication
Corporate accounts
Payment processing
Administrative controls
Reporting
Operational support

But a list of features does not define a product.

The real product was the operating model that connected employees, corporate customers, transportation providers, payments, and support.

This distinction mattered.

A consumer mobility application can optimize primarily for convenience and transaction volume. A corporate platform must also optimize for control, accountability, predictable billing, permissions, reporting, and contractual obligations.

The buyer, user, operator, and payer may all be different people.

That changes almost every design decision.

The Problem We Were Trying to Solve

Corporate transportation was often managed through a fragmented combination of phone calls, spreadsheets, paper vouchers, invoices, local suppliers, and manual reconciliation.

This created several problems:

Limited visibility into usage
Inconsistent authorization
Delayed financial reconciliation
Difficult contract management
Weak auditability
Operational dependency on individual employees
Limited data for planning or negotiation
Poor user experience during incidents

The opportunity was not simply to digitize ride requests.

It was to create a controlled platform through which companies could manage mobility as an operational capability.

That required us to think beyond the passenger interface.

We needed to design for:

Corporate administrators
Operational teams
Financial departments
Transportation providers
Drivers
Employees
Customer-support teams
Commercial stakeholders

Every group had different priorities.

The platform needed to reconcile them.

From Concept to a Commercial Product

The early phase required a combination of product discovery, customer conversations, technical experimentation, and commercial validation.

We needed to determine whether companies would pay for the service and which problems were important enough to change existing behavior.

Some requirements appeared obvious but became more complex under real use.

For example, a corporate ride was not always associated with a single employee. It might involve a visitor, a shift, a project, an operational incident, or a service provider.

Authorization could depend on:

Time of day
User role
Department
Location
Cost center
Contract
Type of transportation
Approval rules

Payments also involved more than charging a card.

The platform needed to connect the operational event—the completed journey—to financial records, customer agreements, pricing rules, and reconciliation processes.

This meant that identity, payment, mobility, and reporting could not be treated as isolated features.

They were part of the same business transaction.

Building the Architecture

TecleTaxi was designed as a cloud-based platform on AWS.

The architecture needed to support:

Web and mobile experiences
Corporate administration
Driver and provider interactions
Geolocation
Authentication
Payments
External integrations
Operational monitoring
Reporting
Customer support

At the time, microservices were becoming increasingly popular, but adopting a highly distributed architecture prematurely would have created operational and organizational costs that the company was not yet prepared to absorb.

We chose a modular approach.

The objective was to create clear boundaries around capabilities such as:

Identity
Corporate accounts
Mobility operations
Payments
Geolocation
Notifications
Reporting
Administration

This allowed the platform to evolve without requiring a large number of independently deployed services from the beginning.

The decision reflected an important principle:

Architecture should match the organization’s current capability while preserving reasonable options for future growth.

A technically fashionable architecture would not have helped if the team could not operate it reliably.

Geolocation and Operational State

Location was an important part of the user experience, but geolocation alone was not the product.

The platform needed to combine location events with operational state.

It was not enough to know where a vehicle was.

We also needed to know:

Whether the ride had been accepted
Whether the driver was approaching
Whether the passenger had boarded
Whether the journey was in progress
Whether it had been completed
Whether an operational exception had occurred
Whether the transaction was ready for financial processing

This required a consistent operational model.

Location data could be delayed, incomplete, or inaccurate. Mobile connectivity could vary. Drivers and passengers could take actions outside the expected sequence.

The system therefore had to tolerate imperfect real-world behavior rather than assume that every event would arrive correctly and in order.

This is a lesson that applies to many digital platforms:

The physical world does not behave like a controlled software test.

Payments and Authentication

Payments and authentication were among the most sensitive capabilities.

Corporate customers needed confidence that:

Only authorized users could request services
Transactions were associated with the correct account
Financial records could be reconciled
Sensitive data was protected
Changes were traceable
Access could be revoked
Administrative actions were controlled

Legacy payment and authentication components had to evolve as the platform matured.

This required balancing modernization with continuity.

Replacing a critical system creates risk. Keeping it indefinitely creates a different kind of risk.

The practical approach was incremental:

Identify the highest-risk limitations.
Establish clearer boundaries.
Introduce modern interfaces.
Migrate capabilities gradually.
Maintain traceability throughout the transition.
Avoid changing too many critical components at once.

The objective was not modernization for its own sake.

It was to improve scalability, security, and operational control without destabilizing the business.

Building More Than an Engineering Team

As the product progressed, the organization expanded to approximately 50 professionals.

The team included capabilities across:

Software engineering
Product
Design
Marketing
Commercial operations
Customer support
Administration

Scaling the organization changed the nature of the work.

When a team is small, information moves through informal conversations. People understand priorities because they are close to the founders and the product.

That stops working as the company grows.

At a larger scale, we needed:

Clearer responsibilities
More explicit priorities
Structured feedback
One-on-one conversations
Development plans
Better coordination across functions
More predictable decision-making
Stronger communication between business and technology

Adding people does not automatically increase delivery capacity.

Without clarity, it can increase coordination cost faster than output.

Leadership therefore became less about personally solving each problem and more about creating the conditions in which other people could solve them.

Cross-Functional Leadership

The most difficult decisions rarely belonged to a single department.

A product change could affect:

Engineering complexity
Customer contracts
Operational processes
Support workload
Marketing commitments
Financial reconciliation
Provider relationships

This made cross-functional leadership essential.

Technical teams needed business context.

Commercial teams needed to understand delivery constraints.

Operations needed visibility into product changes.

Product decisions needed to account for both customer demand and platform sustainability.

The role of leadership was not to eliminate disagreement.

It was to ensure that disagreement happened with shared information and explicit trade-offs.

Fundraising and Expansion

In 2015, I led a funding round that supported the company’s expansion.

Fundraising is often described as a milestone.

It is better understood as a commitment.

New capital creates more options, but it also creates expectations around growth, execution, governance, and results.

The organization now needed to translate investment into:

Product development
Team growth
Commercial expansion
Operational capability
Customer acquisition
Platform reliability

Capital does not solve a weak operating model.

It amplifies the model that already exists.

If priorities are unclear, funding can accelerate waste. If product assumptions are weak, it can scale the wrong solution. If leadership systems are immature, adding people can increase confusion.

The funding round was therefore not an ending.

It increased the importance of disciplined execution.

Commercialization

Turning a product into a commercial offering required more than releasing software.

Corporate customers needed confidence in the entire service.

This included:

Product demonstrations
Contract negotiation
Customer onboarding
User and account configuration
Provider coordination
Operational support
Billing and reconciliation
Incident handling
Reporting
Ongoing relationship management

The product became commercially real when companies incorporated it into their daily operations.

By 2018, TecleTaxi supported multiple active corporate contracts.

That mattered more than whether every original feature had been implemented exactly as imagined.

Commercialization proved that the product could address a real operational need.

It also exposed the difference between product adoption and product operation.

Winning a contract creates the opportunity.

Delivering the service consistently creates the relationship.

Measuring What Mattered

We defined and monitored product and operational indicators around areas such as:

System availability
Incident-resolution time
Customer satisfaction
Contract growth
Operational responsiveness

Metrics were important, but the quality of the definition mattered as much as the number.

For example, system availability could not be treated purely as infrastructure uptime.

A platform might be technically online while a critical payment integration, provider workflow, or authentication capability was unavailable.

The metric needed to reflect whether customers could complete the operation they depended on.

The same applied to incident resolution.

Closing a support ticket did not necessarily mean the operational problem had been resolved.

Useful metrics must represent the customer and business outcome, not merely the internal activity.

What Was Harder Than Expected

Enterprise Customers Need Predictability

Innovation may attract initial interest, but enterprise customers stay because of reliability, support, governance, and trust.

Features help win attention.

Predictability helps retain contracts.

Operational Exceptions Become the Product

The expected workflow is usually straightforward.

The complexity appears when:

A driver cancels
A passenger cannot be located
Connectivity fails
A payment is rejected
A journey is disputed
A provider sends incomplete information
A customer needs an urgent exception

The platform had to support not only the standard process but also the people resolving unusual situations.

Growth Exposes Organizational Weakness

A small team can compensate for unclear processes through effort and proximity.

A larger organization cannot.

Growth exposed the need for clearer ownership, communication, and management practices.

Architecture and Business Cannot Be Separated

A technical decision affected cost, delivery time, operational workload, and commercial commitments.

A commercial decision could introduce architectural complexity or security risk.

Treating business and technology as separate conversations would have produced weak decisions.

The Founder’s Role Must Change

As the organization grows, the behaviors that helped create the product can begin to limit it.

Being involved in every decision may initially provide speed and quality control.

Eventually, it creates dependency.

Leadership must move from direct control toward context, delegation, standards, feedback, and accountability.

Decisions I Would Preserve

Looking back, several decisions were particularly valuable.

Building Around a Real Business Constraint

The product addressed the practical limitations of corporate mobility rather than attempting to reproduce a consumer application for a different audience.

Choosing a Modular Architecture

The modular approach allowed us to maintain clear capability boundaries without adopting more distributed complexity than the organization could operate.

Treating Payments and Identity as Core Capabilities

These were not supporting details. They were central to customer trust and operational control.

Building Cross-Functional Capability

Engineering alone could not create a commercial platform. Product, operations, commercial, support, design, and administration all contributed to the outcome.

Measuring Operational Outcomes

Availability, response time, customer satisfaction, and contract development provided a more realistic view than feature delivery alone.

What I Would Approach Differently Today

Experience changes the questions we ask.

Today, I would place even more emphasis on the following areas from the beginning.

Explicit Product and Domain Boundaries

Clearer domain ownership would reduce ambiguity as the platform and team expanded.

Stronger Observability

Technical metrics, business events, and customer-impact signals should be connected from the start.

Earlier Architecture Decision Records

Important trade-offs should be documented while the context is still fresh, particularly when decisions affect security, financial processing, and operational continuity.

More Structured Experimentation

Product assumptions should be expressed as testable hypotheses with clear success and failure criteria.

Earlier Management Systems

Hiring and team growth should be accompanied by explicit operating principles, role definitions, feedback cycles, and decision rights.

These are not criticisms of the past made with the benefit of hindsight.

They are evidence that building a company changes how one evaluates architecture, product, and leadership.

Lessons From the Journey

1. A Product Is Also an Operating Model

The interface is only the visible part.

Support, contracts, onboarding, payments, reconciliation, providers, and incident handling are part of the product customers experience.

2. Architecture Must Match Organizational Maturity

The best architecture is not the one with the most advanced patterns.

It is the one the organization can build, understand, operate, and evolve responsibly.

3. Enterprise Trust Is Built Through Unremarkable Capabilities

Authorization, reporting, reconciliation, auditability, support, and predictable operations are rarely the most exciting parts of a product.

They are often the reasons a customer can adopt it.

4. Growth Requires Leadership Systems

A larger team needs more than additional meetings.

It needs clear ownership, expectations, feedback, development, communication, and decision processes.

5. Funding Increases Accountability

Investment creates opportunity, but it also increases the cost of unclear priorities and weak execution.

6. Commercialization Is a Different Discipline From Development

A working product is necessary.

It is not sufficient.

The organization must be able to sell, onboard, support, operate, bill, and retain customers.

7. End-to-End Accountability Changes Technical Judgment

Once you are responsible for the product, team, customers, contracts, operations, and capital, architecture can no longer be evaluated in isolation.

Every decision becomes part of a larger system.

How the Experience Shaped My Later Work

After leaving the Managing Director role, I returned to software and solution architecture.

The transition may have looked unusual.

In practice, the TecleTaxi experience made me a better architect.

I had learned to evaluate technical decisions through a broader lens:

Customer value
Organizational capability
Operational risk
Delivery constraints
Financial sustainability
Team ownership
Long-term change

Years later, while working with cloud platforms, data systems, and enterprise AI products, the underlying questions remained familiar.

Can the organization operate what we are designing?

Can users trust the result?

What happens when a dependency fails?

Who owns the outcome?

Does the complexity create enough value to justify its cost?

The technology changes.

The need for accountable engineering does not.

Conclusion

TecleTaxi Corporativo began as an attempt to solve a practical B2B mobility problem.

It became a lesson in product development, cloud architecture, payments, operations, fundraising, commercialization, team scaling, and leadership.

The most important outcome was not a specific feature or technology.

It was understanding that successful products emerge from the alignment of several systems:

The software
The business model
The organization
The operational process
The customer relationship
The decisions made under pressure

Building the platform required technical knowledge.

Commercializing and scaling it required something broader: the ability to connect technology, people, capital, operations, and customer needs around a shared outcome.

That remains one of the most valuable lessons of my career.