DEV Community: Canopus agency

Web, Mobile and SEO: why small businesses should stop treating them as three separate projects

Canopus agency — Wed, 28 Oct 2026 09:43:40 +0000

Most small businesses I work with come to me with one of three requests. "We need a new website." "We need an app." "We need to rank on Google."

They almost always treat these as separate jobs, hired out to separate people, at separate times. And that's usually where the money gets wasted.

I run Canopus Web Agency, a small studio doing web development, mobile apps and SEO for SMBs, mostly in France and Belgium. After a few years of building sites for taxi companies, towing services, local shops and SaaS founders, here's what I've learned about why these three things belong in the same conversation.

1. The website is the foundation, not the brochure

A lot of sites are still built like printed flyers: nice homepage, an "about" page, a contact form, done.

The problem is that Google doesn't rank flyers. It ranks pages that answer specific questions. A taxi company in Bordeaux doesn't need one "Services" page, it needs a page for airport transfers, one for the train station, one for long distance trips, each one with real content and real prices.

So before anyone writes a line of CSS, the page structure should already be planned around what people search for. If you build the site first and "add SEO later", you end up rebuilding half of it.

What I check before starting a build:

Which searches actually bring customers (not just traffic)
One page per intent, no "everything" pages
Clean URLs that won't need to change in a year
A CMS the client can actually update without calling me

2. Performance is an SEO feature and a sales feature

On mobile, a slow site loses people before they see anything. Core Web Vitals are part of how Google judges a page, but honestly the bigger reason to care is conversion. Someone booking a ride at 6am from their phone will not wait 5 seconds for a slider to load.

A few things that make the biggest difference on the projects I do:

Drop the heavy page builder effects nobody asked for
Serve images in WebP/AVIF with proper sizes
Load third-party scripts (chat widgets, trackers) late or not at all
Cache properly, and test on a real cheap Android phone, not just your laptop

3. Do you actually need a mobile app?

Sometimes yes. Often no.

If your customers use your service once a year, a fast mobile website will do the job better than an app they have to install. If they use it every week (drivers, delivery staff, repeat clients, internal teams), an app starts to make sense: push notifications, offline mode, saved data, faster repeat actions.

When an app does make sense, I usually build it with React Native / Expo so it ships on Android and iOS from one codebase, and it talks to the same backend as the website. One source of truth for bookings, users and content. That way the site and the app never disagree with each other.

4. SEO is not a one-time task

The sites that rank well in my experience share a few boring habits:

They publish useful content regularly, written for their actual customers
Their Google Business Profile is complete and gets reviews
Their name, address and phone are the same everywhere online
They fix technical issues as they appear instead of once every 3 years
They have structured data (LocalBusiness, FAQ, Service) set up properly

None of this is magic. It just needs someone to keep doing it.

5. Put it together

Here's how I'd plan it for a small business starting from scratch:

Keyword and competitor research first, so you know what pages to build
A fast, well-structured website built on that plan
Local SEO setup (Google Business Profile, citations, schema)
Content added month after month
A mobile app only when usage data shows people would come back to it

Doing it in this order costs less than doing it backwards, and each step makes the next one easier.

If you're a developer, I'd be curious how you handle the SEO side with your own clients. Do you plan it before the build or bring someone in after?

And if you run a business and want help with any of this, you can find my work at canopuswebagency.com.

How to Build a WordPress Plugin Licensing System from Scratch (Without Freemius)

Canopus agency — Wed, 17 Jun 2026 09:53:06 +0000

If you're shipping a commercial WordPress plugin, sooner or later you'll need a licensing system. Something that lets paying customers activate the plugin on their site, locks it to that domain, and stops people from sharing the same key across fifty sites.

The default answer in the WordPress world is Freemius or EDD Software Licensing. They're great. They're also a revenue share, a third-party dependency, and a black box you don't control.

When we built RideCab WP, a commercial WooCommerce taxi booking plugin, we decided to build our own. Here's the architecture, the code, and the gotchas we hit along the way.

What a Licensing System Actually Needs to Do

Before writing any code, get clear on the requirements. A real plugin licensing system needs to:

Generate unique license keys when someone buys
Let the customer activate the key on their site
Bind that key to one (or N) domains
Validate the key periodically so revoked or expired keys stop working
Handle deactivation when a customer moves to a new domain
Fail gracefully — never lock a paying customer out because your license server hiccuped
Optionally: deliver plugin updates only to valid license holders

We'll cover 1 through 6 in this post. Update delivery is a separate beast and I'll write it up next.

The Architecture

The system has two halves that live in two different places.

The license server runs on your own infrastructure — for us, it's a WordPress must-use plugin (mu-plugin) on the same WordPress install that powers our marketing site. It:

Stores license keys in a custom database table
Exposes a small REST API for activate, deactivate, and validate calls
Provides an admin dashboard to view, create, and revoke keys

The client is a PHP class shipped inside the commercial plugin (RideCab WP, in our case). It:

Adds a license settings page to the plugin
Calls home on activation
Caches the validation result
Re-validates quietly in the background

Two pieces, talking over HTTPS, with the customer's domain as the binding key.

Step 1: The License Server — Database Schema

On the server side, the simplest workable schema is one table:

`php
global $wpdb;
$table = $wpdb->prefix . 'plugin_licenses';

$sql = "CREATE TABLE $table (
id BIGINT(20) UNSIGNED NOT NULL AUTO_INCREMENT,
license_key VARCHAR(64) NOT NULL,
customer_email VARCHAR(191) NOT NULL,
product_slug VARCHAR(64) NOT NULL,
status ENUM('active','revoked','expired') DEFAULT 'active',
activations LONGTEXT NULL,
max_activations TINYINT UNSIGNED DEFAULT 1,
expires_at DATETIME NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
UNIQUE KEY license_key (license_key)
) {$wpdb->get_charset_collate()};";

require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
`

The activations column is a JSON-encoded array of { domain, activated_at } pairs. For more than a few products this should probably be a separate table — but for most plugin authors, JSON in one column is plenty.

Step 2: Generating License Keys

Keep them short enough to be typed if needed, long enough to be unguessable. A common pattern is four blocks of uppercase hex:

php function generate_license_key() { $blocks = []; for ( $i = 0; $i < 4; $i++ ) { $blocks[] = strtoupper( bin2hex( random_bytes( 4 ) ) ); } return implode( '-', $blocks ); // Example: 9F3A2B71-C8D4E5F6-1A2B3C4D-5E6F7081 }

random_bytes() is cryptographically secure. Don't use rand() or uniqid() for license keys — they're predictable.

Hook key generation into your order completion flow. If you're using WooCommerce on the server side to sell the plugin, that's woocommerce_order_status_completed.

Step 3: The REST API

Three endpoints are enough. Register them on rest_api_init:

php add_action( 'rest_api_init', function() { register_rest_route( 'license/v1', '/activate', [ 'methods' => 'POST', 'callback' => 'license_activate', 'permission_callback' => '__return_true', ] ); register_rest_route( 'license/v1', '/deactivate', [ 'methods' => 'POST', 'callback' => 'license_deactivate', 'permission_callback' => '__return_true', ] ); register_rest_route( 'license/v1', '/validate', [ 'methods' => 'POST', 'callback' => 'license_validate', 'permission_callback' => '__return_true', ] ); } );

The activate handler is the most important one:

`php
function license_activate( WP_REST_Request $req ) {
$key = sanitize_text_field( $req->get_param( 'license_key' ) );
$domain = sanitize_text_field( $req->get_param( 'domain' ) );

if ( ! $key || ! $domain ) {
    return new WP_REST_Response( [ 'success' => false, 'message' => 'Missing parameters' ], 400 );
}

global $wpdb;
$table   = $wpdb->prefix . 'plugin_licenses';
$license = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM $table WHERE license_key = %s", $key ) );

if ( ! $license ) {
    return new WP_REST_Response( [ 'success' => false, 'message' => 'Invalid license key' ], 404 );
}
if ( 'active' !== $license->status ) {
    return new WP_REST_Response( [ 'success' => false, 'message' => 'License is ' . $license->status ], 403 );
}
if ( $license->expires_at && strtotime( $license->expires_at ) < time() ) {
    return new WP_REST_Response( [ 'success' => false, 'message' => 'License expired' ], 403 );
}

$activations = json_decode( $license->activations, true ) ?: [];
$existing    = array_filter( $activations, fn( $a ) => $a['domain'] === $domain );

if ( ! $existing && count( $activations ) >= (int) $license->max_activations ) {
    return new WP_REST_Response( [ 'success' => false, 'message' => 'Activation limit reached' ], 403 );
}

if ( ! $existing ) {
    $activations[] = [ 'domain' => $domain, 'activated_at' => current_time( 'mysql' ) ];
    $wpdb->update( $table, [ 'activations' => wp_json_encode( $activations ) ], [ 'id' => $license->id ] );
}

return new WP_REST_Response( [
    'success'    => true,
    'expires_at' => $license->expires_at,
], 200 );

}
`

The validate and deactivate handlers follow the same pattern: look up the license, check status, update activations as needed.

Step 4: The Client Class

This lives inside the commercial plugin. It's what calls the server.

`php
class Plugin_License_Client {

const OPTION_KEY   = 'my_plugin_license_key';
const TRANSIENT    = 'my_plugin_license_valid';
const API_BASE     = 'https://yourdomain.com/wp-json/license/v1';
const CACHE_PERIOD = WEEK_IN_SECONDS;

public function is_valid() {
    $cached = get_transient( self::TRANSIENT );
    if ( false !== $cached ) {
        return (bool) $cached;
    }
    $valid = $this->remote_validate();
    set_transient( self::TRANSIENT, $valid ? 1 : 0, self::CACHE_PERIOD );
    return $valid;
}

public function activate( $license_key ) {
    $response = wp_remote_post( self::API_BASE . '/activate', [
        'timeout' => 15,
        'body'    => [
            'license_key' => $license_key,
            'domain'      => $this->current_domain(),
        ],
    ] );
    if ( is_wp_error( $response ) ) {
        return [ 'success' => false, 'message' => 'Could not reach license server' ];
    }
    $body = json_decode( wp_remote_retrieve_body( $response ), true );
    if ( ! empty( $body['success'] ) ) {
        update_option( self::OPTION_KEY, $license_key );
        set_transient( self::TRANSIENT, 1, self::CACHE_PERIOD );
    }
    return $body;
}

private function remote_validate() {
    $key = get_option( self::OPTION_KEY );
    if ( ! $key ) {
        return false;
    }
    $response = wp_remote_post( self::API_BASE . '/validate', [
        'timeout' => 10,
        'body'    => [
            'license_key' => $key,
            'domain'      => $this->current_domain(),
        ],
    ] );
    if ( is_wp_error( $response ) ) {
        // Fail open: don't punish customers for our server being down.
        return true;
    }
    $body = json_decode( wp_remote_retrieve_body( $response ), true );
    return ! empty( $body['success'] );
}

private function current_domain() {
    return wp_parse_url( home_url(), PHP_URL_HOST );
}

}
`

Notice the // Fail open comment in remote_validate(). This is the single most important design decision in the whole system.

Step 5: Fail Open, Not Closed

When your license server is unreachable — and it will be unreachable sometimes, because the internet is the internet — what should happen?

Fail closed: the plugin disables itself until it can re-validate. Customers see a broken site. They email you. Your reputation craters.

Fail open: the plugin keeps working. A small percentage of bad actors might get a few extra hours of unlicensed use. So what.

Always fail open. Your paying customers are the ones you have to protect, and they're the ones who suffer most when validation calls fail. Pirates will pirate either way.

A reasonable middle ground: cache the last successful validation for a week. If the server is unreachable, keep working off the cache for up to 30 days. After 30 days of no successful validation, show a non-blocking admin notice. Never disable the plugin outright.

Step 6: The Settings Page

Customers need a place to enter their key. A minimal settings page does the job:

`php
add_action( 'admin_menu', function() {
add_options_page(
'My Plugin License',
'My Plugin License',
'manage_options',
'my-plugin-license',
'render_license_page'
);
} );

function render_license_page() {
$client = new Plugin_License_Client();

if ( isset( $_POST['license_key'] ) && check_admin_referer( 'my_plugin_license' ) ) {
    $result = $client->activate( sanitize_text_field( wp_unslash( $_POST['license_key'] ) ) );
    echo '<div class="notice notice-' . ( $result['success'] ? 'success' : 'error' ) . '"><p>'
        . esc_html( $result['message'] ?? 'License activated.' ) . '</p></div>';
}

$current = get_option( Plugin_License_Client::OPTION_KEY );
?>
<div class="wrap">
    <h1>License</h1>
    <form method="post">
        <?php wp_nonce_field( 'my_plugin_license' ); ?>
        <input type="text" name="license_key" value="<?php echo esc_attr( $current ); ?>" class="regular-text" />
        <?php submit_button( 'Activate License' ); ?>
    </form>
</div>
<?php

}
`

In production you'll want better UX — show the activation status, the bound domain, a deactivate button. But this is the minimal viable settings page.

Common Mistakes to Avoid

A few things I've seen go wrong, both in our system and in others:

Validating on every page load. Kills performance, multiplies failure modes. Cache it.
Hardcoding the license server URL with http://. Use HTTPS. Always.
Storing license keys in plain options without sanitization. Treat them like passwords on input.
Not handling the staging/dev case. Customers will test on staging.theirsite.com. Decide whether you grant a free extra activation for *.dev, *.local, staging.*, or whether you fail and document the workaround. Either is fine; just decide before you ship.
No way for customers to deactivate themselves. They will switch domains. They will rebuild sites. Give them a self-service deactivate button.
Logging full license keys server-side. If your server is ever compromised, those logs become a treasure map. Log the last 4 characters only.

What's Next

This system covers everything except update delivery — letting valid license holders pull plugin updates from your server instead of WordPress.org. That's its own write-up because it involves WordPress's pre_set_site_transient_update_plugins filter and serving zipped plugin packages from your server. I'll cover it in a follow-up.

If you want to see this system running in production, it's what powers licensing for RideCab WP, our commercial WooCommerce taxi booking plugin. Same architecture as above, with a few extra layers for domain wildcards and team licenses.

Questions on any part of this? Drop them in the comments — happy to go deeper on the API design, the caching strategy, or the failure modes.

Building a Taxi Booking Plugin for WooCommerce — Lessons from the Trenches

Canopus agency — Wed, 17 Jun 2026 09:50:03 +0000

When we started building RideCab WP, a WooCommerce-based taxi booking plugin, we underestimated almost everything. Booking flows look simple from the outside: pick up here, drop off there, pay. Under the hood, it's a maze of edge cases.

This post is a brain dump of the technical decisions, dead ends, and lessons from building a commercial WordPress plugin for a real business niche: taxi and fleet operators who want to take bookings from their own website without paying SaaS fees or per-ride commissions forever.

Why WordPress + WooCommerce?

The taxi industry is full of expensive SaaS platforms that charge per booking and lock operators into someone else's ecosystem. Most small fleet owners already have a website — usually WordPress — and don't want a separate dashboard, separate billing, and a 15% cut on every ride.

WordPress + WooCommerce gives us:

Existing checkout and payment gateway infrastructure
Order management UI that fleet owners already understand
A massive plugin and theme ecosystem
Zero recurring fees for the operator

The tradeoff: WooCommerce's data model is built for physical and digital products, not service bookings with dynamic pricing. Bending it to fit took real work.

Custom Product Type vs. Custom Post Type

The first big architectural decision: should a "ride booking" be a WooCommerce product or a separate entity?

We tried both. A pure custom post type gave us full control but meant rebuilding cart, checkout, and payment integration from scratch. A pure custom WooCommerce product type kept us inside WooCommerce's flow but fought us on every dynamic pricing rule.

The answer was a hybrid: a custom WooCommerce product type (ridecab_booking) that delegates pricing to a separate fare engine. Each booking becomes a real WooCommerce order, but the price is calculated server-side at add-to-cart time from distance, zones, and vehicle type — not stored as a fixed product price.

\php add_filter( 'woocommerce_product_class', function( $classname, $product_type ) { if ( 'ridecab_booking' === $product_type ) { $classname = 'WC_Product_RideCab_Booking'; } return $classname; }, 10, 2 ); \\

This let us reuse WooCommerce's tax calculation, coupon system, and email notifications for free.

The Fare Calculation Problem

This is where 70% of the complexity lives.

A real taxi fare isn't just distance × rate. You're dealing with:

Base fare + per-km rate + per-minute rate
Zone-based pricing (airport surcharges, city center premiums)
Vehicle class multipliers (standard, premium, van)
Time-of-day modifiers (night rates, weekend rates)
Minimum fares
Round-trip discounts
Distance calculation between two real-world points

We tried Haversine distance (straight-line) first. It was useless — drivers don't fly. Real fares need driving distance, which means a routing API. We integrated Google Distance Matrix as the default and made the integration pluggable so operators can swap in OSRM, Mapbox, or other providers.

The fare engine itself ended up as a chain of modifiers — each rule (base, distance, time, vehicle, zone) is applied in sequence, and each can be enabled, disabled, or overridden per operator. Keeping each rule as a small, independent class made testing far easier than the giant if/else block we started with.

Handling Bookings as WooCommerce Orders

A booking has data WooCommerce doesn't natively understand: pickup location, drop-off location, scheduled time, vehicle, passenger count, flight number, special notes.

We attach all of this as order item meta:

\php add_action( 'woocommerce_add_order_item_meta', function( $item_id, $values ) { if ( isset( $values['ridecab_pickup'] ) ) { wc_add_order_item_meta( $item_id, '_pickup_location', $values['ridecab_pickup'] ); wc_add_order_item_meta( $item_id, '_dropoff_location', $values['ridecab_dropoff'] ); wc_add_order_item_meta( $item_id, '_scheduled_time', $values['ridecab_time'] ); } }, 10, 2 ); \\

Then we filter the order admin screen and the customer email to surface this data clearly. A fleet dispatcher needs to see "Pickup: 14 Avenue Habib Bourguiba at 9:30 AM" the moment they open the order, not buried under a list of meta fields.

The Licensing System

A commercial plugin needs license keys, domain locking, activation/deactivation, and update delivery. Most developers reach for Freemius. We chose to build our own, partly for control, partly to avoid the revenue share.

The architecture is two pieces:

A server-side mu-plugin that generates and validates license keys against an admin dashboard, with domain binding.
A client-side class inside the plugin that calls home on activation, caches the response, and re-validates quietly in the background.

The key insight: don't validate the license on every page load. That kills performance and creates downtime if your license server has a hiccup. Validate on activation, cache the result for several days, and re-validate quietly in the background.

\php class RideCab_License { public function is_valid() { $cached = get_transient( 'ridecab_license_valid' ); if ( false !== $cached ) { return (bool) $cached; } $valid = $this->remote_validate(); set_transient( 'ridecab_license_valid', $valid ? 1 : 0, WEEK_IN_SECONDS ); return $valid; } } \\

This pattern — cache aggressively, fail gracefully, never block the admin UI — is the difference between a licensing system users tolerate and one they hate.

What We'd Do Differently

A few honest reflections:

We over-engineered the fare engine early. A simple distance-based fare would have covered 80% of customers on day one. We built for the 20% edge cases before the 80% was solid.
We underestimated documentation. A commercial plugin lives or dies on its docs. We treat docs as code now: versioned, reviewed, shipped with releases.
We should have set up update delivery from day one. Pushing updates manually for the first few customers was painful.
Test coverage on the fare engine paid for itself ten times over. Pricing bugs are the kind users notice immediately and remember forever.

The Result

RideCab WP is now in production with real fleet operators running their booking sites on it. You can see the result at https://ridecabwp.com — one-time license, no commission, no per-booking fees.

If you're building commercial WordPress plugins, the meta-lesson is this: WooCommerce is a powerful foundation, but you'll spend more time bending it than extending it. Plan for that, lean on its hooks instead of fighting its data model, and ship the 80% before you chase the 20%.

Happy to answer questions in the comments — especially on the fare engine architecture or the licensing approach. The licensing system in particular is its own rabbit hole; I'll write that one up next.