<![CDATA[Omolade Odetara’s Insights: Strategic Analysis, Product Engineering, and Tech Trends]]>https://omoladeodetara.hashnode.devRSS for NodeTue, 23 Jun 2026 13:36:01 GMT60<![CDATA[PriceRouter: A Control Plane for Seller Pricing]]>https://omoladeodetara.hashnode.dev/pricerouter-a-control-plane-for-seller-pricinghttps://omoladeodetara.hashnode.dev/pricerouter-a-control-plane-for-seller-pricingMon, 18 May 2026 06:52:21 GMT

PriceRouter is OpenRouter for pricing workflows: one API and one policy layer to connect commerce data, price intelligence, product matching, and execution engines.

Seller pricing is fragmented. A merchant who wants to set the right price across two marketplaces and a Shopify store typically pays for one tool to monitor competitors, another to match SKUs, another to compute recommendations, another to push price updates to each channel : and stitches them together with brittle integrations. PriceRouter sits above that stack as a normalized control plane: one schema, one policy engine, one audit trail, and routing logic that decides which downstream system gets which action.

This memo lays out the problem, the proposed product, the MVP wedge, and the questions a build team would have to answer.

The argument for building this

The case for PriceRouter is not "another pricing tool." It is that the right layer to build right now is the seam between the pricing tools that already exist : and that no incumbent is incentivized to build it.

1. The seams are where merchants actually lose. Every multichannel seller already has the pieces: a storefront, one or two marketplaces, a competitor monitoring feed, a matcher, a repricer or rules engine, and a spreadsheet that reconciles the gaps. The failure mode is not missing software. It is brittle integrations between software, manual reconciliation between sources that disagree, and a queue of exceptions a human triages every morning. The product that wins is the one that turns that morning queue into a governed pipeline : not the one that adds a tenth tool to the stack.

2. The wedge is orchestration, not replacement. A control plane can ship value the day it connects to one storefront, one marketplace, one observation feed, one matcher, and one repricer. It does not require the merchant to rip out anything they already trust. That is the opposite shape from a closed pricing suite, which has to be better than every component it replaces before a buyer will switch. Orchestration only has to be better than a spreadsheet at the seams : and the spreadsheet is a very low bar.

3. "Router" is a category, not a metaphor. OpenRouter is not "middleware for LLMs" : it is the layer where model choice, fallbacks, policy, and billing get expressed once and routed many times. PriceRouter is the same shape for pricing: data sources, matchers, and execution targets get expressed once, and policy routes decisions across them with confidence scoring and an audit trail. Calling it "middleware" undersells it; calling it a "router" names a buyer-facing product surface (one API, one policy, one trail) that incumbents do not have a clean answer to.

4. The most ambitious thing to price is the pricing decision itself. Catalog syncs, observations, and matching jobs are honest billable units, but the ceiling on willingness-to-pay sits with the automated pricing decision : the unit of work that replaces a human's morning queue and ships an auditable price change to a live channel. That is what merchants actually pay for outcomes against, and it is the unit a control plane can credibly govern. Anything narrower (per-API-call, per-SKU sync) prices the input. Pricing the decision prices the value.

5. Why now is the unbundling, not the technology. Unified commerce APIs, third-party price monitoring APIs, dedicated matching services, and repricer APIs have all shipped. The market is finally fragmented enough across credible vendors that an orchestration layer has somewhere to orchestrate to. Five years ago there was no PriceAPI to plug into and no SP-API price-adjustment workflow to call; the layer had nothing to route. Today the seam exists because the components exist : and because no single vendor in that list can credibly route to its competitors, the seam will not be closed by an incumbent.

6. The moat compounds where the components don't. Connectors are commoditizing. Observation feeds and matchers will keep churning. The thing that does not commoditize is the normalized data model the merchant's policy is written against, the routing logic that knows which source to trust for which category, the confidence and explanation systems that make automation safe enough to leave running, and the audit trail that makes regulated buyers possible. Every one of those gets stronger with usage in a way that an individual repricer's market share does not.

The honest one-line version of the bet: build the layer where merchants express pricing policy once, route decisions across whichever vendors are best this quarter, and keep an audit trail strong enough to defend every price change. That layer does not exist today, the components it would route to all do, and the buyer pain it removes is felt every morning. That is the argument for doing this.

Problem

Seller pricing workflows are split across separate tools for store connectivity, competitor price monitoring, product matching, and price execution. Repricing systems each need deep integrations with shopping platforms and marketplaces, and unified-integration vendors exist precisely because direct connections are operationally painful to build and maintain. Product matching is its own technical problem : it needs candidate sets, scoring logic, and confidence thresholds before any downstream price decision can be trusted.

The result is a stack where merchants face brittle integrations, manual reconciliation between data sources, and trust issues whenever match quality or rule outcomes are unclear. Buyers don't just feel "fragmentation" abstractly; they feel it as a queue of exceptions a human has to triage every morning.

Proposed product

PriceRouter exposes a unified API for four jobs:

  1. Ingest catalog and channel data from commerce platforms.

  2. Collect external price observations from monitoring providers.

  3. Score product matches with explicit confidence values.

  4. Route recommendations or approved price changes to internal or third-party execution engines.

The first end-to-end user journey is concrete: connect Shopify and Amazon, ingest competitor observations, score matches, apply margin floors, and send approved actions to a repricer or to the marketplace API. A merchant connects channels once, picks data sources, defines policy (margin floors, competitor sets, MAP rules), and then routes recommendations to a native engine or a connected repricer.

Architecture

The core system has six services:

  • Connector service : normalizes catalog, channel, and order data from commerce platforms and marketplaces.

  • Observation service : ingests structured price, availability, and promotion data from external monitoring APIs.

  • Matching service : returns confidence-scored candidates rather than yes/no matches, so the policy engine can decide what to act on.

  • Policy engine : evaluates rules (floors, margins, competitor sets, MAP) before any automated action is sent downstream.

  • Execution router : pushes recommendations or approved updates to internal engines, third-party repricers, or marketplace APIs (Amazon SP-API, Shopify Admin, etc.).

  • Audit log : every input, score, decision, and outbound action is recorded so humans can explain a price change after the fact.

Amazon's own pricing automation guidance reinforces this shape: rule-based workflows, notifications, and programmatic price submission are how production-grade price management actually runs.

MVP

A focused MVP targets mid-market multichannel merchants with a recommendation-first workflow rather than full autopilot from day one. The first release should include:

  • Unified SKU import across at least one marketplace and one storefront.

  • Competitor observation ingestion from one or two providers.

  • Confidence-scored matching with a tunable threshold.

  • A rules engine for floor price and margin logic.

  • Approval queues for low-confidence cases.

  • Outbound webhooks or API actions to repricers and marketplaces.

This scope is narrow enough to ship and broad enough to prove the control-plane value proposition. It also keeps the wedge focused on orchestration and trust, which is where defensibility likely lives.

Why now

The enabling pieces already exist: unified commerce APIs, third-party price monitoring APIs, product matching services, and repricer APIs. The opportunity is not to rebuild each piece from scratch : it is to standardize how they connect and how merchants express pricing policy across them.

Monetization

Usage-based pricing is the natural fit because the product generates discrete billable events: catalog syncs, price observations, matching jobs, and execution actions. A practical structure is a platform fee based on active SKU volume plus usage charges for observations, matching, and automated execution, with premium tiers for enterprise support and SLAs. Pure pay-per-event is probably too punitive for buyers who already understand connected-store pricing in adjacent integration tools, so a hybrid is safer commercially.

Defensibility

The strongest moats are likely:

  • A normalized data model that other tools start to depend on.

  • Provider routing logic that learns which sources are reliable for which categories.

  • Policy abstractions that survive vendor swaps.

  • Confidence and explanation systems that increase merchant trust.

  • Auditability that makes regulated and enterprise buyers possible.

Over time, benchmark data on match quality, execution outcomes, and rollback performance becomes a real switching cost. Scraping alone is not the moat.

Risks

The biggest risks are operational, not technical:

  • Poor product matching at scale erodes trust faster than any feature can rebuild it.

  • Inconsistent source quality : observation feeds disagree, and the system has to express uncertainty rather than hide it.

  • Marketplace-specific rule complexity : Amazon, eBay, and Shopify each have constraints that don't generalize cleanly.

  • Merchant reluctance to delegate pricing changes to automation, which is why the recommendation-first MVP exists.

These risks argue for a phased rollout: recommendations and approval queues first, then guarded automation, then fully automated routing for the rule-defined cases.

Near-term roadmap

  1. Unified schema and connector layer for one storefront platform and one marketplace.

  2. Observation ingestion and matching with confidence thresholds and exception handling.

  3. Policy engine and execution router that can push recommendations or approved price updates to a third-party repricer and at least one marketplace API.

Once those three are in place, the rest of the roadmap is about depth (more connectors, better matching) rather than additional surface area.

Why "OpenRouter for pricing" is the right framing

OpenRouter abstracts fragmented model providers behind one API, with routing policy, fallbacks, and managed billing. PriceRouter does the same thing for commerce platforms, price feeds, matching services, and repricers. The framing is useful because it tells the buyer what shape of product this is : a routing and control layer, not yet another repricer. It also explains why "router" is the right word: the product routes decisions and actions across a fragmented stack, with confidence scoring and auditability built in.

A weaker version of the pitch is "router for pricing," because that sounds like middleware. The stronger pitch keeps the OpenRouter analogy and adds the policy and audit story.

Why one schema isn't enough

The honest version of "unified API for pricing" is that no single schema cleanly absorbs every commerce platform, observation feed, matcher, and repricer. Different pricing systems don't just name fields differently; they encode different concepts, workflows, and constraints. Some expose simple price updates, others depend on notifications, batch feeds, marketplace-specific rules, or confidence-scored matching outputs. Once you add custom fields, merchant-specific overrides, and marketplace quirks, a rigid universal schema starts to break down.

This is the same N×M problem that classic enterprise integration hit decades ago: with N data sources and M targets, point-to-point integrations explode. Middleware collapses it to N+M with a canonical model : at the cost of slow, political schema design and silent fidelity loss whenever a provider exposes something the canonical model never anticipated.

The right goal for PriceRouter is not "universal perfect mapping." It is high-coverage canonical mapping plus explicit extension points for what doesn't fit.

Mapping architecture

The pattern that actually works in production unified APIs is layered, not flat:

  • Canonical core for the shared pricing primitives every merchant needs: product identity (SKU, GTIN, variant attributes), offer state (price, currency, availability, channel), observations (competitor price, source, timestamp, confidence, buy-box signals), match output (candidates, score, threshold, reviewer status), and actions (recommend, approve, submit, rollback).

  • Adaptive provider mappings that translate request and response payloads between the canonical core and each connected platform, observation feed, matcher, or repricer.

  • Passthrough/extension layer for fields and endpoints the canonical model doesn't cover : vendor-specific metadata, marketplace-specific rule shapes, custom merchant fields. These travel through PriceRouter without being forced into the core.

  • Provider capability metadata so the policy engine and execution router know which actions a given downstream system actually supports.

The right framing is: PriceRouter maps all pricing data through a layered architecture : canonical core for decisions, adaptive mappings for providers, passthrough for edge cases. That is much stronger than either extreme of "one schema for everything" or "just forward whatever arrives," and it matches how mature unified-API platforms (Truto, Unified.to, Apideck, Merge) describe their own architectures.

AI-assisted translation for the long tail

The long tail of partner schemas, version skew, and one-off integrations is where deterministic adapters become the bottleneck. This is where LLM-mediated translation : what Tian Pan calls LLMs as universal protocol translators : fits inside PriceRouter, but only as AI-assisted translation with hard contracts, not "AI magically understands anything."

The viable architecture for that piece:

  1. Merchant-side schema intake: docs, examples, payload history, and optional plain-English field descriptions.

  2. AI mapper that produces a typed intermediate representation plus confidence scores.

  3. Vendor contract compiler that emits the exact outbound payload for the chosen downstream system.

  4. Runtime validator that checks required fields, enums, types, and policy rules before any execution call.

  5. Response normalizer that converts vendor output back into the merchant's preferred schema or canonical event format.

  6. Human review path for low-confidence mappings, schema drift, or newly seen fields.

The model is the smart translator, but the platform decides whether the translation is valid enough to execute. Emerging standards like the Model Context Protocol point at how this kind of capability discovery and tool invocation gets formalized : useful for the discovery-and-mapping layer of PriceRouter, less appropriate for the execution boundary.

A practical hybrid pattern: use the LLM to draft and propose adapters at integration time, then freeze the mature mapping into deterministic code once routing logs show it is stable. The routing telemetry PriceRouter already collects becomes the training signal for the next adapter.

When to trust AI translation

The decision framework for a pricing control plane is sharper than for general middleware:

  • Use AI-mediated translation for: partner onboarding with idiosyncratic schemas, draft adapter generation, schema discovery on a new feed, normalizing low-stakes observation fields, and explaining unexpected vendor responses to humans.

  • Require deterministic adapters for: actual price submission to marketplaces (Amazon SP-API, Shopify Admin), MAP enforcement, audit-grade decisions, anything subject to compliance review, and any path where a hallucinated mapping could ship a wrong price to live customers.

The failure mode to avoid is assuming the model can safely infer everything forever. Schema drift, hidden semantics, and undocumented edge cases still need contracts, monitoring, and fallback controls. So the honest product claim is not "we map everything." It is "PriceRouter normalizes the common pricing workflow, safely routes the exceptions, and uses AI to translate the long tail under hard contracts."

References

]]><![CDATA[The Pricing Layer: Why the Most Powerful Layer in Commerce Isn't Payments]]>https://omoladeodetara.hashnode.dev/the-pricing-layer-why-the-most-powerful-layer-in-commerce-isn-t-paymentshttps://omoladeodetara.hashnode.dev/the-pricing-layer-why-the-most-powerful-layer-in-commerce-isn-t-paymentsMon, 18 May 2026 06:51:43 GMT

The Pricing Layer

Without price, there is no payment. Without valuation, there is no exchange. Without exchange, there is no payment.

Pricing precedes payments. Payments are merely the settlement of a pricing decision.

For two decades, the most valuable companies in commerce infrastructure have been payment companies : Visa, Mastercard, PayPal, Stripe, Adyen. We talk about them as if they sit at the center of the economy. They don't. They sit at the end of it.

The center is pricing. And in an AI-native economy, that fact is about to become very expensive for anyone who hasn't noticed.

The Five-Layer Commerce Stack

Every commercial transaction, no matter how simple or how algorithmic, moves through five layers:

# Layer What it does Who dominates today
1 Discovery Finding products and services Google, Amazon, TikTok, App Stores
2 Pricing Determining value : what to charge, when, to whom, under what conditions Fragmented. No dominant platform.
3 Transaction Executing the payment Stripe, Adyen, PayPal
4 Settlement Moving the money between institutions Card networks, ACH, RTP, stablecoins
5 Ledger Recording ownership and accounting ERPs, accounting SaaS, on-chain ledgers

Stripe dominates layer 3 and partially layer 4. That's a $150B+ valuation for owning execution.

Layer 2 : the decision layer : has no Stripe. It is, today, the most valuable empty seat in commerce infrastructure.

Why Payments Won the Last Era

Payments became enormous because the hard problems of the last forty years were:

  • Digitizing transactions.

  • Establishing trust between strangers.

  • Moving value across banking and regulatory regimes.

  • Building global settlement networks.

Those problems were genuinely hard, and the companies that solved them earned generational wealth. Visa was effectively a B2B routing protocol with a brand on top. Stripe wrapped the same routing in seven lines of code and a developer-friendly API.

But notice what those companies don't do: they don't decide what anything is worth. They take that as input.

Why Pricing Wins the Next Era

In an AI-driven economy, the hard problem is no longer moving the money. It's deciding the number.

  • Prices change continuously, not quarterly.

  • AI agents negotiate autonomously on both sides of a transaction.

  • Supply and demand shift in seconds, not seasons.

  • Personalization becomes individualized, not segmented.

  • Marketplaces become algorithmic, not catalog-based.

In that world, the entity controlling pricing controls the flow of commerce itself. Payments become commoditized infrastructure : fast, cheap, embedded, and increasingly invisible.

This is why every category-defining company is, at its core, a pricing company in disguise:

  • Amazon obsesses over pricing algorithms.

  • Airlines built yield management decades before anyone called it AI.

  • Uber is fundamentally a surge-pricing engine bolted onto a dispatch network.

  • Ad exchanges are auction-pricing engines.

  • Cloud providers compete on usage pricing as much as on hardware.

  • AI labs live and die by token pricing.

Whoever controls pricing shapes behavior, allocates resources, influences demand, extracts margins, and ultimately governs market dynamics. Payments only moves the cash.

The Stripe Acquisition Question

A useful thought experiment: which is more likely : Stripe acquires a major dynamic pricing company, or a major dynamic pricing company acquires Stripe?

Today, the answer is obvious. Stripe is a roughly $159B private fintech with a long history of acquiring vertically into adjacent infrastructure: tax automation, billing, fraud, treasury, stablecoins. A pricing acquisition is a natural extension. Stripe is already publicly evolving from "payments processor" to "full revenue operating system," with usage-based AI billing and adaptive monetization features that openly hint in this direction.

The reverse : a pricing company acquiring Stripe : is implausible at current scale. Stripe is too large, holds too many regulatory licenses, and operates too much physical payments infrastructure for a SaaS pricing optimizer to absorb.

But if a pricing company became truly dominant : owning real-time price discovery, demand forecasting, inventory allocation, margin optimization, and liquidity formation across airlines, logistics, retail, energy, cloud, AI agents, advertising, and financial markets : it would no longer be a SaaS company. It would be market infrastructure, closer to an economic operating system than to software.

In that world, acquiring Stripe looks less like "SaaS buys fintech" and more like Bloomberg buying a brokerage: the pricing engine decides what to charge, when, to whom, under what conditions; the payments network simply executes.

That is the asymmetric bet behind the pricing layer.

What "Owning the Pricing Layer" Actually Requires

A pricing layer is not "software that changes prices." That's a feature. To become real infrastructure, a pricing platform needs:

  1. Proprietary data : observed prices, observed elasticity, observed willingness-to-pay across enough surfaces to be unignorable.

  2. Network effects : every additional buyer, seller, and experiment makes everyone else's pricing better.

  3. AI superiority : models that genuinely beat human pricing committees, in production, at scale.

  4. Embedded distribution : sitting inside checkout flows, billing engines, marketplaces, and agent runtimes by default, not as an integration.

  5. Real-time orchestration : the ability to decide and push prices in milliseconds, not nightly batch jobs.

Sectors where this is plausible in the next decade:

  • Airline and travel ecosystems (the original yield-management vertical, still fragmented).

  • Cloud compute marketplaces.

  • Electricity grids (real-time wholesale, demand response).

  • Autonomous AI commerce (agent-to-agent negotiation).

  • Logistics and freight exchanges.

  • B2B procurement marketplaces.

Each one is a place where the pricing decision is harder, more frequent, and more economically consequential than the payment that follows it.

The Wedge: Agent-to-Agent AI Inference Pricing

Picking the right wedge matters more than picking the right thesis. Airline yield management is the obvious romantic answer : it's where pricing was invented as a discipline, it's where the original pricing analysts learned their craft, and it's a market measured in trillions. It is also a fortress: every major carrier has fifty years of in-house Revenue Management infrastructure, calcified vendor relationships with the incumbents, and regulators who treat pricing changes as filings rather than experiments. You don't wedge into airlines. You spend a decade selling into airlines.

The right wedge has the opposite shape. It needs to be:

  1. Real-time by default : humans cannot price it manually, so there is no incumbent committee to displace.

  2. Machine-readable on both sides : buyer and seller are already programs, not browsers.

  3. Growing fast enough that last quarter's pricing is already wrong : the spreadsheet-from-finance approach actively destroys margin.

  4. Without an entrenched yield-management discipline : nobody has owned this category for thirty years.

  5. Naturally agentic : the buyer is already an autonomous process making thousands of decisions per second.

There is exactly one market that satisfies all five today: agent-to-agent AI inference pricing.

Every AI agent in production right now : coding agents, customer-support agents, research agents, browser agents : is buying inference from somewhere. OpenAI, Anthropic, Google, Bedrock, Together, Fireworks, Groq, Replicate, plus an exploding long tail of fine-tuned open models on commodity GPUs. The buyer is a piece of software. The seller is a piece of software. The decision happens in milliseconds and repeats billions of times per day. And the pricing today is embarrassingly primitive: static per-token rate cards, manually updated.

This is the wedge for these reasons:

  • The customer is already a developer. The buyer for "smarter inference pricing" is the same person buying Stripe, Vercel, and Datadog. Same procurement model, same self-serve adoption curve, same willingness to integrate via API on a Friday afternoon.

  • The data exhaust is the moat. Every routed request produces a labeled training signal: "for this kind of prompt, model X at price Y delivered quality Z and latency L." After enough volume, the routing decisions become impossible to replicate without the data.

From that wedge you expand outward : agent-to-agent commerce more broadly (data, tools, compute, sub-agent calls), then SaaS usage-based pricing, then the harder verticals (cloud compute, B2B procurement). Luxury and electricity grids are the third market, not the first.

The Acquisition Inversion

The conventional version of this story ends with Stripe writing a big check. That's the comfortable version, because it preserves the existing hierarchy: the payments giant remains the apex predator and merely absorbs an interesting feature set. It is also, almost certainly, wrong.

Layers of infrastructure don't get acquired by the layers below them. They acquire downward. The decision layer always eats the execution layer, never the reverse. A few historical reference points:

  • Google → DoubleClick. The decision layer (which ad to show, to whom, at what bid) bought the execution layer (the ad-serving plumbing). Not the other way around.

  • Amazon → AWS billing. Amazon never asked a payments processor to build retail. Retail decisions ate the rails underneath them.

  • Visa → CyberSource. When Visa wanted gateway capability, it bought one. The network owned the decision layer and the rails; the gateway was the executor.

The shape always rhymes: whoever owns the decision eventually subordinates whoever owns the execution. Execution is a feature of decisions. Stripe is a feature of pricing.

What This Means for Builders

If you accept that pricing is the next layer of commerce infrastructure, three implications fall out:

1. Treat pricing as a product, not a setting. The number on your pricing page is the most-edited input in your business and the least-instrumented. That asymmetry is the opportunity. Run experiments. Measure elasticity. Version your pricing the way you version your code.

2. Build for agents, not just humans. The buyer of the next decade is increasingly an autonomous agent acting on behalf of a human or a business. Your pricing surface needs to be machine-readable, queryable in real time, and capable of negotiating : not a static page rendered for a browser.

3. Don't outsource the decision to your payments stack. Stripe will happily charge whatever number you give it. That convenience hides the strategic question: who decided that number, with what data, against what objective? If the answer is "a spreadsheet from last quarter," you've already lost the layer.

The Thesis, Compressed

Discovery finds the thing. Pricing decides what it's worth. Transaction executes the payment. Settlement moves the money. Ledger records the result.

Stripe owns layer 3. The next $150B company owns layer 2. And then it owns layer 3 too.

Without price, there is no payment.

Whoever controls price controls commerce.

The future belongs to pricing engines.

]]><![CDATA[Networking, Nightlife, and New Tech: My CloudFest 2025 Story]]>https://omoladeodetara.hashnode.dev/networking-nightlife-and-new-tech-my-cloudfest-2025-storyhttps://omoladeodetara.hashnode.dev/networking-nightlife-and-new-tech-my-cloudfest-2025-storySun, 11 May 2025 16:39:33 GMTFrom Nice to Europa-Park and Into the Heart of Cloud Innovation

CloudFest 2025 was more than just a conference-it was an experience that started the moment I left home. As someone passionate about cloud technology and the WordPress ecosystem, attending this event in Europa-Park, Rust, Germany, was a bucket-list moment. Let me take you through my journey, from the logistics of getting there to the electric atmosphere inside the park, and why CloudFest is truly unlike any other tech gathering.

Getting There: Planes, Trains, and Cloud Shuttles

My CloudFest adventure began with a flight from Nice to Strasbourg (SXB), one of the closest airports to Rust. From there, I hopped on a train, soaking in the scenic beauty of the Black Forest region as I made my way toward the small but vibrant town of Rust. The journey itself was smooth and surprisingly enjoyable-Strasbourg’s connections to Ringsheim and Offenburg make getting to Europa-Park easier than you’d expect, even if it feels like you’re heading to the middle of nowhere.

Arriving at the train station, I was greeted by the dedicated CloudFest shuttle service-a lifesaver for attendees. These shuttles run frequently, connecting key train stations directly to Europa-Park and the official conference hotels. The anticipation built as the bus wound its way through Rust, finally delivering us to the gates of what would be our home for the week.

First Impressions: Europa-Park as a Tech Wonderland

Europa-Park is not your average conference venue. Imagine Disneyland, but with a distinctly European flair and a tech twist. The park is massive, colorful, and buzzing with excitement-especially when 8,000+ cloud professionals descend for CloudFest. The energy was palpable from the moment I stepped in.

Navigating the park was part of the adventure. Whether taking the scenic monorail, strolling through the picturesque streets of Rust, or catching a shuttle between hotels and sessions, every route offered a new perspective and a chance to bump into fellow attendees. The logistics team deserves a medal for keeping everything running smoothly.

The Event: A Festival of Ideas and Connections

CloudFest isn’t just about keynotes and booths (though there were plenty of both). It’s a true festival, with a schedule packed from morning to night. Here are some highlights from my week:

  • Hackathon Kickoff: The event opened with a Hackathon, drawing developers and open-source enthusiasts to collaborate on projects that could shape the future of cloud services. Even as a spectator, the buzz of creativity was infectious.

  • WordPress Day: March 17 was all about WordPress, with sessions focused on AI, security, and agency growth. It was inspiring to see leaders from Automattic, Elementor, and other major players sharing insights and pushing boundaries.

  • Expo and Sessions: With over 80 talks, fireside chats, and masterclasses, there was never a dull moment. The new WP Zone was a particular highlight, serving as the epicenter for WordPress innovation and community.

  • Networking Like Nowhere Else: CloudFest’s legendary parties-Come2Gather, Shamrock Shake, ConneXion, and BierFest-were more than just fun; they were where real connections happened. Whether at a themed party or an impromptu gathering at the Colosseo Bar, I met people who are shaping the future of the internet.

Practical Tips for Future Attendees

  • Plan Your Journey: Book your flights and trains early, and check the CloudFest shuttle schedule for seamless transfers.

  • Stay Charged: The CloudFest app is essential for networking, so bring a power bank to keep your devices alive.

  • Map Out Meetings: With so many attendees, scheduling meetings in advance (and sticking to CET time!) is crucial for meaningful conversations.

  • Enjoy the Park: Don’t rush-take time to explore Europa-Park itself. The setting is half the magic.

Reflections: Why I’ll Be Back

CloudFest 2025 was a whirlwind of innovation, learning, and genuine human connection. From the moment I boarded my flight in Nice to the late-night conversations in Rust, every part of the journey reinforced why this event is a must for anyone in the cloud or web hosting industry. It’s not just about technology-it’s about the people, the ideas, and the unforgettable memories created along the way.

]]><![CDATA[Google's rumoured HubSpot Acquisition: Strategic Analysis]]>https://omoladeodetara.hashnode.dev/googles-rumoured-hubspot-acquisition-strategic-analysishttps://omoladeodetara.hashnode.dev/googles-rumoured-hubspot-acquisition-strategic-analysisSun, 07 Apr 2024 22:00:00 GMTDistilling the All-in Pod discussion

There was a rumour that Google is considering a bid to acquire HubSpot

HubSpot is a customer platform that connects the tools businesses need to deliver customer experiences. It is a CRM that blends marketing and sales. Google with a $2 Trillion market cap needs no introduction but I’ll say that their ad revenue hit $237.8 billion in 2023. As of May 2024, HubSpot has a $34 billion market cap. Hubspot shareholders could expect a purchase price of approximately $50 billion if Google pays a premium on this.

Here, I’ll discuss what this acquisition means for Google's network of advertisers and Hubspot customers.

TL;DR, Google has ad data but doesn’t have sales data

Hubspot

Today Hubspot provides integrated marketing automation software like CRM tools and email marketing. Whenever you run ads and generate leads from ad platforms like Facebook, google etc..your sales team and the marketing team would generally use a CRM like Salesforce, Hubspot etc to track and manage the leads to convert them.

Google

According to David Friedberg when he worked at Google in 2005 the main thing he worked on was how to provide more tools for advertisers. One of those deals included acquiring Urchin in 2005 which later became Google Analytics. This allowed companies to better track how leads were converting on their website after they spent marketing dollars on Google.

Google also considered acquiring a CRM like Salesforce led by Mark Benoff, although it was richly valued and had IPOed. And NetSuite which was eventually rolled in by Larry Ellison into Oracle for $9.3 billion in November 2016.

They considered a few other CRM companies in search of the next solution that you plug into the advertising including checkout software before the launch of Google Checkout which wasn’t too successful.

Strategic relevance

As I mentioned earlier Google made roughly a quarter trillion dollars last year in advertising revenue and then they didn't make much revenue after the advertising generated leads.

Regulatory Scrutiny

The M&A world today is almost non-existent, there is a lot of scrutiny from the Federal Trade Commission especially when the purchasing party is in the “four commas’ club” i.e. companies worth over a trillion dollars.

Looking at the failed Adobe-Figma or the very successful Meta-Instagram in these examples, the acquisitions were defensive because it was about taking out a competitor and safeguarding their market position.

Protecting the ad business

But in a conventional sense, Hubspot isn’t a competitor to Google’s ad network businesses. This acquisition would likely be viewed differently because it expands Google’s market presence and capabilities in the marketing and sales software industry. With this Google improves its ad targeting and gives advertisers more tools that can integrate with the AdWords platform as a result it locks the advertisers in and reinforces the status quo. By keeping the advertisers more engaged Google protects its ad Revenue from leakage.

HubSpot makes two billion in Revenue so it's 1% of the size of Google's ad business. Friedberg makes the point that selling CRM services may be generally lucrative but in this case, the marginal impact they'll get from this SaaS is not that impactful to the business.

Vendor Lock-in

Sachs wonders what Google accomplishes here that they couldn't do with an integration or a partnership. And yes there already exists a connector between Google ads going to make it a roach motel lock-in you get in and you can't get out because the full life cycle of the advertiser exists within the same ecosystem.

This move would enable Google to offer an end-to-end marketing solution, combining its strong advertising platform with HubSpot’s CRM and marketing automation tools.

Contrarian view

Companies use HubSpot to manage their pipelines it's a competition to Salesforce due to its ease of use and user-friendliness and the main thing it does is you have your pipeline in there you bring in the leads at the top of the funnel and work them down to close deals where do those leads come from I understand that they can come from Google AdWords but if you're one of the customers of HubSpot Google AdWords is just one of several channels you could be getting your leads through inbound you could be getting your leads through events you could be getting your leads through I mean there's so many.

Closing the loop

JCal makes the case that the key piece to this is the data. There are the leads and the great contacts in the database of the customer which Google doesn't have access to they can close the loop and they can improve the targeting of ads, get people deeper and fight for a larger percentage.

For example, you've got 20 different inbound leads coming. If Google knows the leads in your sales pipeline, and at what stage of the sales funnel they are in, or just identifies your 10,000 best customers and thousands of others not fully converted and also knows when they're on Google search, in a Chrome browser, on an Android device, Google Display Network (GDN), YouTube Ads etc. The leads can be retargeted across Google’s entire ad Network which is the largest in the world. And you get to spend more of your ad dollars to fully convert those leads.

Sales data

We can deduce that this deal is not about the SaaS business it is about the data that can be used to retarget prospects and close more sales.

However, Chamath raises the question of ethics and whether companies will allow Google to use their customers' data. In reality, if Google tells you you have 20,000 people in your CRM database 8,000 of whom came in through Google search, do you want to go find the other 12,000 across Google’s ecosystem? It is a no-brainer. It could be more efficient than TikTok and Facebook/meta. This recursive loop and data on sales are how Amazon, Uber and Instacart have become major players in advertising.

Product Integration and ROI

Friedberg says that just improving conversion rates drives more ad revenue and the key measurement within Google the year after they bought urchin and launched Google Analytics was how much advertisers spent on Google's AdWords Network before and after they installed Google Analytics and that year they saw an incremental $500 million in Revenue in ad spend.

HubSpot has 205,000 customers as of the end of 2023 and Google AdWords has 1.2 million businesses paying $2000 on average these advertisers do not 100% overlap with Hubspot customers but if Google can drive 5% of those to use Hubspot and to spend 10% to 30% more on ad it would pay for the acquisition over a short period.

]]><![CDATA[The Great Debate: Revolution vs. Evolution in Product & Engineering. (Part 2).]]>https://omoladeodetara.hashnode.dev/the-great-debate-revolution-vs-evolution-in-product-engineering-part-2https://omoladeodetara.hashnode.dev/the-great-debate-revolution-vs-evolution-in-product-engineering-part-2Mon, 26 Jun 2023 22:00:00 GMTTL;DR for Part Two: The Case for Incremental Refinements.

This article advocates for incremental refinements, emphasizing the benefits of gradual improvements that enhance functionality, reduce risks, and maintain user familiarity without the upheaval of a full redesign. For insights into why a more radical approach might sometimes be necessary, see Part One: The Case for Comprehensive Redesigns.

The Case for Incremental Improvements

Incremental improvements, iterative design or iterative development or deployment, is a method where changes are made gradually and continuously. This approach allows designers and developers to adjust and refine elements of the software based on user feedback and behavioral data without overhauling the entire system. One of the significant advantages of this approach is minimizing disruption to the user experience. Users can adapt to small changes more easily than to a completely revamped interface.

Moreover, incremental improvements can be more cost-effective and less risky compared to a full redesign. They allow for continuous testing and adaptation, which can lead to a more user-centered design over time. This method aligns well with agile development practices, where the focus is on making continuous improvements through regular updates.

Incremental Improvements: The Case for Evolutionary Design

Incremental improvements, also referred to as iterative design, are rooted in the principles of continuous development and agile methodologies. This approach advocates for gradual, consistent updates based on user feedback and data analytics, allowing for the refinement of software without disrupting the core functionality that users have come to rely on.

Why Incremental Changes Aren't Enough

Incremental changes, while safe and minimally disruptive, typically offer only superficial improvements. They can keep a product functioning and prevent immediate decline, but they rarely address deeper issues of usability and modernity. Over time, these piecemeal adjustments create a patchwork of features that may lack cohesion, ultimately leading to a clunky and outdated user interface.

Moreover, in a world where technology and user expectations are rapidly evolving, sticking to minor updates can cause a product to lag significantly behind its competitors. New entrants in the market often capture attention and market share by introducing bold, innovative designs that make older products look obsolete by comparison.

Advantages of Incremental Improvements:

  • User Familiarity and Satisfaction: By making small, predictable changes, developers can maintain a stable user experience that builds on existing user knowledge and interaction patterns.

  • Risk Mitigation: Incremental changes minimize the risks associated with larger system overhauls, including bugs, user rejection, and implementation failures.

  • Continuous Feedback Loop: This method benefits from ongoing user feedback, which is integrated into successive updates, ensuring that the product evolves in alignment with user needs and preferences.

Limitations of Incremental Improvements:

  • Design Debt Accumulation: Over time, small updates may lead to inconsistencies and a patchwork appearance, as new features may not be fully integrated with the overall design ethos.

  • Innovation Stagnation: There is a risk of becoming too focused on minor tweaks at the expense of broader, more innovative leaps that could redefine user engagement and market positioning.

Impact of Technical and Design Debt on the Decision to Refine

  • Technical Debt: If the technical debt is manageable, it might be more efficient and less disruptive to address specific issues through incremental improvements. This approach allows teams to refine the system piece by piece, tackling the most pressing issues first without a complete system overhaul.

  • Design Debt: Incremental design improvements can be effective when the overall design concept remains solid but needs adjustments to enhance usability or modernize aesthetics. This could involve updating color schemes, improving the accessibility of the interface, or gradually standardizing disparate elements across the user experience.

The Role of Leadership in Redesigns

The decision to initiate a full redesign should not be taken lightly and requires substantial support from company leadership. The process is not just a design challenge; it’s a business decision that impacts all aspects of the organization. Successful redesigns often need a champion at the executive level to secure the necessary resources and to align the redesign with broader business objectives. This top-down support is crucial to navigate the challenges and resistances that can arise.

While incremental improvements will always have their place for minor tweaks and refinements, the most successful companies will be those that are not afraid to periodically reinvent themselves. It is these bold redesigns that clear away accumulated inefficiencies and set new standards in design, functionality, and user satisfaction.

Conclusions

In conclusion, the decision to adopt an incremental or comprehensive approach should be informed by a strategic assessment of user needs, market demands, and long-term business goals. The debate is not about which method is superior, but rather which is most appropriate under specific circumstances. Future research could further delineate the conditions under which one strategy might outperform the other, potentially offering a more nuanced framework for software design decisions.

]]><![CDATA[The Great Debate: Revolution vs. Evolution in Product & Engineering (Part 1)]]>https://omoladeodetara.hashnode.dev/the-great-debate-revolution-vs-evolution-in-product-engineering-part-1https://omoladeodetara.hashnode.dev/the-great-debate-revolution-vs-evolution-in-product-engineering-part-1Fri, 26 May 2023 22:00:00 GMTIn the rapidly evolving world of product development, the visual and functional aspects of a product are pivotal to user satisfaction and market success. Businesses are constantly pressured to innovate or be left behind. As products age and expand, they accumulate what's known as "design debt" — mismatches and inconsistencies that creep in as features are added and the market evolves. This debt, if not managed, can degrade the user experience and make the software feel outdated. This brings us to an important crossroad many organisations face: deciding when to undertake a full-scale redesign versus incremental improvements.

TL;DR for Part One: The Case for Comprehensive Redesigns

This article argues for the necessity of comprehensive redesigns in product development, highlighting their ability to overhaul outdated systems, address extensive technical and design debts, and reinvigorate user interfaces for competitive advantage. For a contrasting perspective on adopting a more cautious approach, see Part Two: The Case for Incremental Refinements.

Some advocate for cautious, incremental improvements to avoid disrupting the user experience, this approach often leads to stagnation and missed opportunities. Here, I argue for the necessity of embracing full-scale redesigns—not as a last resort, but as a proactive, strategic decision essential for staying relevant and competitive.

Understanding Debt

Design debt or tech debt refers to problems within the user experience and/or the underlying functionality that accumulate over time as quick and dirty solutions are implemented. These might include inconsistent styles, confusing navigation, or features that no longer fit seamlessly within the product. If left unaddressed, debt can lead to decreased user satisfaction and hinder the onboarding of new users.

The concepts of technical debt and design debt are deeply relevant to the debate on whether to undertake comprehensive redesigns versus focusing on incremental refinements in product development. Each type of debt can influence the decision-making process, affecting when and how a product should be updated. Understanding how these debts accumulate and their impact is crucial for making informed choices about the future direction of a software product's development.

When a Full Redesign is Necessary

A full redesign is necessary when the underlying architecture of the software limits the potential for new features, or when the product has evolved to serve a different purpose or audience than it originally did. A full redesign can also be a strategic response to significant shifts in the market or emerging technologies that necessitate a complete rethinking of how the product is structured and delivered.

A redesign can rejuvenate a product, potentially re-engaging existing users and attracting new ones. It can also provide an opportunity to address large swaths of design debt all at once, creating a more coherent and updated user experience.

Comprehensive redesigns advocate for a fundamental reevaluation and overhaul of a software product’s interface and functionality. This approach is often driven by significant shifts in technology, user expectations, or business strategy that demand more radical changes than incremental updates can provide.

Despite the benefits of incremental changes, there are scenarios where a full redesign is necessary. This is often the case when the underlying architecture of the software limits the potential for new features, or when the product has evolved to serve a different purpose or audience than it originally did. A full redesign can also be a strategic response to significant shifts in the market or emerging technologies that necessitate a complete rethinking of how the product is structured and delivered.

The Strategic Advantage of Bold Redesigns

A full redesign is a powerful tool for repositioning a product or brand within its market. It signals to users and competitors alike that the company is serious about innovation and committed to delivering the best possible experience. This can rejuvenate a brand's image, attract new users, and re-engage existing ones who might be drifting away in search of fresher alternatives.

Redesigns also provide an opportunity to reevaluate and restructure the user experience from the ground up, integrating the latest technologies and design principles. This is not just about aesthetics; it’s about rethinking how users interact with the product, making it more intuitive, efficient, and enjoyable. Such an overhaul can significantly enhance user satisfaction and loyalty, leading to increased engagement and retention.

Advantages of Comprehensive Redesigns:

  • Addressing Fundamental Usability Issues: Allows product teams to address deep-seated usability and functional issues that incremental changes cannot resolve.

  • Rebranding and Repositioning: Redesigns can reinvigorate a product and reposition a company within the market, attracting new users and refreshing the brand.

  • Integration of Modern Technologies: Comprehensive overhauls provide an opportunity to integrate newer technologies and design principles that are not compatible with the old architecture.

Limitations of Comprehensive Redesigns:

  • Higher Risks and Costs: The costs and risks of a full redesign are significant, with the potential for higher failure rates and substantial financial investments.

  • User Disruption: Sudden changes can alienate existing users, especially if the new design shifts dramatically from familiar interaction patterns.

Impact of Technical and Design Debt on the Decision to Redesign

  • Technical Debt: When technical debt reaches a critical point—where the cost of maintaining old code outweighs the investment required for a redesign—a full system overhaul can become necessary. This kind of overhaul isn’t just about improving the current functionalities but about rethinking the architecture to allow easier updates, better security, and improved performance in the future.

  • Design Debt: Similarly, significant design debt might prompt a comprehensive redesign. If the user interface becomes too clunky or inconsistent, or if it significantly lags behind modern usability standards and aesthetic trends, a full redesign can reinvigorate user engagement and ensure the product meets contemporary user expectations.

The Role of Leadership in Redesigns

The Necessity of Executive Backing

Undertaking a full redesign is not for the faint-hearted. It requires substantial investment and can be risky. However, the greatest transformations often come from bold moves.

Executive backing is crucial in these endeavors—not only to secure the necessary resources but to foster an environment where radical ideas can be explored and implemented without undue fear of failure.

This process is not just a design challenge; it’s a business decision that impacts all aspects of the organization. Successful redesigns often need a champion at the executive level to secure the necessary resources and to align the redesign with broader business objectives.

Leadership must not only support the initiative but actively promote a vision for what the product can become.

Embracing Change to Stay Ahead

The tech industry does not reward those who play it safe. Companies like Apple and Tesla have not risen to the top by cautiously updating their products but by periodically redefining expectations for what their products can be. In this spirit, more companies should embrace the concept of complete redesigns as a necessary strategy for innovation and growth.

While incremental improvements will always have their place for minor tweaks and refinements, the most successful companies will be those that are not afraid to periodically reinvent themselves. It is these bold redesigns that clear away accumulated inefficiencies and set new standards in design, functionality, and user satisfaction.

Comparative Analysis and Strategic Implications

The choice between incremental improvements and comprehensive redesigns depends on various factors including the company’s market position, user base dynamics, and technological trends. For companies with a stable user base and minor usability issues, incremental improvements might be the most effective strategy. Conversely, in industries characterized by rapid technological advancements and shifting user expectations, comprehensive redesigns may be necessary to stay competitive.

Considerations for Choosing Between Redesign and Refinement

  • Scope and Scale of Debt: The extent and nature of both technical and design debt should be assessed. Minor debts can often be corrected through refinements, while substantial debts might necessitate a more radical redesign approach to reset the foundation effectively.

  • Resource Availability: Redesign projects require significant resources, not only in terms of budget and personnel but also time. Companies need to consider their capacity to invest in a major overhaul versus smaller, ongoing updates.

  • User Impact: Any decision should consider the user impact. A full redesign might disrupt the user experience temporarily but can lead to a much better product. Conversely, refinements might be less disruptive in the short term but could prolong the existence of fundamental design or technical flaws.

  • Market and Competitive Landscape: The decision might also be influenced by external factors such as market demands and competitive pressure. If competitors are offering more advanced, user-friendly interfaces, a full redesign might be necessary to remain competitive.

Conclusions

Deciding between an incremental update and a full redesign involves weighing the current state of the product, the needs and behaviors of its users, and the strategic goals of the organization. While incremental improvements are generally less disruptive and more cost-effective, a full redesign might be necessary to realign the product with its intended market and to address significant usability flaws.

In either scenario, the ultimate goal is to enhance the user experience and ensure the product continues to meet and exceed user expectations. A balanced approach, one that considers both the business impact and the user needs, will likely yield the most beneficial results for any software product.

]]><![CDATA[Building Frameworks: Championing Global Lunar Policy]]>https://omoladeodetara.hashnode.dev/building-frameworks-championing-global-lunar-policyhttps://omoladeodetara.hashnode.dev/building-frameworks-championing-global-lunar-policyWed, 15 Feb 2023 23:00:00 GMTFrom Lagos to the Moon: How I Became a Voice for Global Space Policy

When I traded Lagos’ bustling markets for Strasbourg’s cobblestone streets, I thought I was just joining a startup. Instead, I found myself on a Zoom call with the United Nations, advocating for the future of lunar exploration-all while representing an industry, a nation, and a vision I hadn’t fully grasped until that moment.

From Lagos to the Moon, my journey has taken me from developing tech in Nigeria to advocating for global space policy at the United Nations. Joining Lee Space, I unexpectedly found myself involved with the Global Expert Group on Sustainable Lunar Activities (GEGSLA), aiming to establish guidelines for peaceful and collaborative lunar exploration.

An Unlikely Journey: From Local Developer to UN Delegate

My story starts in Nigeria, where tech innovation thrives despite infrastructure gaps. When I joined Lee Space, a company incubated at the International Space University (ISU), I imagined building software for satellites, rockets and space assets, not policy frameworks for the Moon. But life has a way of catapulting you into unexpected orbits.

One Tuesday morning, an email arrived: “Invitation to present at the United Nations Committee on the Peaceful Uses of Outer Space (UNCOPUOS).”

The GEGSLA Framework: A Rulebook for Moon Villages

Let’s rewind. GEGSLA-the Global Expert Group on Sustainable Lunar Activities-isn’t just another acronym. It’s a multi-year collaboration between countries, space agencies, companies, and academics to answer one question: How do we prevent the Moon from becoming a cosmic Wild West?

Imagine this: private companies mining lunar ice, nations setting up research bases, and startups offering Moon tourism-all within a decade. Without rules, we’d face chaos: conflicting land claims, environmental damage, and missed opportunities for collaboration.

The GEGSLA Framework is our collective attempt to avoid that future. Think of it as a mix of “guidelines for polite neighbors” and “technical standards for survival.” Here’s what it tackles:

  1. Transparency: Share your lunar plans so others don’t accidentally crash into your rover.

  2. Environmental Care: Protect the Moon’s delicate dust (which is sharper than glass and ruins equipment).

  3. Interoperability: Ensure everyone’s tech plays nice-like making sure a Japanese lander can dock with a European habitat.

  4. Inclusivity: Invite developing nations to the table before the menu is set.

Why I Spoke for Nigeria-and Why It Matters

When I unmuted myself on that Zoom call, I wasn’t just representing my company. I was there for Nigeria, a country with a budding space program but limited resources. Here’s the hard truth: if you’re not at the table, you’re on the menu.

Historically, space has been dominated by a few wealthy nations. But the Moon is different. It’s a global commons, and its resources-like water ice in shadowed craters-could unlock deep-space exploration for all of humanity. My key message was simple:

“Developing nations aren’t charity cases. We’re contributors. Involve us in drafting the rules, and you’ll get better rules.”

For example, Nigeria’s experience leapfrogging landlines to build a mobile-first economy could inspire creative solutions for lunar infrastructure. But if we’re excluded from early discussions, that potential is lost.

Representing Nigeria, I emphasized the importance of inclusivity and innovation from developing nations in space policy. Although the GEGSLA Framework is voluntary, it encourages cooperation, reduces risks, and sets standards to prevent chaos on the Moon. Our mission is to transition from a competitive space race to a mindset of shared destiny for humanity's future in space.

The Industry Paradox: Innovators Need Guardrails

As a private sector rep, I faced a tightrope walk. Companies want freedom to innovate, but chaos on the Moon would hurt everyone. The GEGSLA Framework strikes a balance:

  • For Startups: Clear rules reduce risk for investors. (No one funds a lunar hotel if land rights are ambiguous.)

  • For Giants like SpaceX or Blue Origin: Standards prevent costly conflicts. (Imagine two rovers blocking each other’s solar panels.)

  • For Everyone: Shared norms mean more collaboration-like pooling data to avoid redundant experiments.

The Elephant in the (Virtual) Room: Who Enforces This?

Here’s the hitch: the GEGSLA Framework isn’t legally binding. It’s a voluntary “playbook” for doing the right thing. Skeptics argue that without enforcement, bad actors will ignore it. But I’ve seen firsthand how peer pressure works in tech.

Open-source software thrives because no one wants to be the developer who breaks the community’s trust. Similarly, companies adopting GEGSLA’s guidelines gain credibility. (Try selling “sustainable lunar mining” to ESG investors without them.)

The framework also nudges nations to formalize agreements through COPUOS-the UN’s space committee-where Nigeria and other developing countries have equal voting rights.

What’s Next? From Zoom Calls to Lunar Colonies

Since that UN session, GEGSLA has entered its “operational phase.” We’re workshopping the framework with startups, hosting webinars for emerging space nations, and pushing for an Action Team on Lunar Activities Consultation (ATLAC)-a COPUOS group to troubleshoot disputes.

But the real work is cultural. We’re shifting from a zero-sum “space race” to a mindset of shared destiny. When I think about the future, I picture:

  • A Nigerian engineer tweaking a lunar rover design from her Lagos coworking space.

  • A Vietnamese startup using GEGSLA guidelines to secure funding for a Moon-based solar farm.

  • Astronauts from Brazil and India sharing data on lunar water extraction.

Final Thought: Space Is the Ultimate Collaboration

My journey from Lagos to Strasbourg to a UN Zoom grid taught me one thing: the next era of space won’t be defined by rockets alone. It’ll be shaped by policy, partnerships, and the quiet power of showing up-even virtually.

Through my involvement with GEGSLA, I've seen the potential for collaborative guidelines to prevent chaos on the Moon, while emphasizing the role of developing nations like Nigeria in shaping these rules. Despite the framework's voluntary nature, it's a vital step toward transforming the space race into a shared destiny for humanity's future in space. This narrative underscores the significance of policy, partnerships, and being present at the table where decisions are made.

The GEGSLA Framework isn’t perfect. But like the early internet protocols that let incompatible computers communicate, it’s a starting point. And sometimes, just showing up-with a bold idea, a Nigerian accent, and a stable Wi-Fi connection-is enough to change the game.

So here’s to the dreamers, the coders, and the diplomats. The Moon is waiting. Let’s build a future there that’s worthy of the best of humanity-all of humanity.

Want to dive deeper? Check out the full GEGSLA Framework

https://www.youtube.com/watch?v=lVa453ivuCE
]]>