How to Build a White-Label Auction Platform for Your Clients

What white-labelling actually means

White-labelling is the practice of taking a product built by one company, removing that company's branding, and delivering it under a different brand — typically your client's. In software, this means replacing logos, colour schemes, company names, email templates, and any visible references to the original developer with the client's own brand identity. The underlying code is unchanged; the surface presentation is entirely the client's.

For an agency or freelance developer, white-labelling a PHP auction script like BidKing means you can deliver a production-ready auction platform to a client in days rather than months, at a fraction of the cost of bespoke development, while presenting it as a custom-built product under the client's brand. The client gets a professional platform. You get a large margin between the script cost and your project fee. The script author sells more licences. Everyone wins.

Most quality CodeCanyon scripts explicitly permit white-labelling — either under their standard licence terms or through a direct arrangement with the developer. BidKing is one of them: WowCodes offers explicit white-labelling arrangements for agencies and developers who need to deploy the platform under client branding. Contact us to discuss your specific requirements.

The licence question

Before you modify a single file, you need to understand how licences work for CodeCanyon scripts — because getting this wrong creates legal exposure for you and your client.

Envato (the company behind CodeCanyon) has two licence tiers for marketplace scripts:

• Regular licence: Covers one deployment where the end product is free for end users to use. Appropriate when you're installing the script on a client's server for their own internal use, or running a platform where user participation is free.
• Extended licence: Required when the end product is sold or monetised — i.e., where end users pay to use the product. This covers commercial SaaS deployments and client projects where the client will charge their own users.

For the typical agency white-label scenario — a client who wants to run a public auction platform where their customers pay to bid — an Extended licence per deployment is the correct structure. One Extended licence covers one client deployment. If you have three auction platform clients, you need three Extended licences.

The customisation scope for a white-label

A complete white-label job covers more than just swapping a logo. Here is the full scope of what needs to change for a proper rebrand.

• Logo and favicon: Replace all instances of the WowCodes/BidKing logo with the client's logo in the correct formats (SVG for the primary logo, PNG for email headers, ICO/PNG for the favicon). Check the admin panel, public-facing pages, email templates, and PWA manifest separately — logos appear in more places than you'd expect.
• Colour scheme: Modern PHP scripts use CSS custom properties (variables) for colour theming, which means a complete colour rebrand can often be done by editing a single variables file. BidKing uses CSS variables throughout — changing the primary colour, accent colour, and background values in the root variables file propagates the change across the entire platform instantly.
• Company name throughout the platform: Search the codebase for all instances of "BidKing" and "WowCodes" and replace with the client's platform name. This includes page titles, meta descriptions, default email subjects, footer text, and any hardcoded strings in the PHP files. A global find-and-replace across the codebase handles this in minutes.
• Email templates: All transactional emails (registration confirmation, outbid notification, auction close, winner notification, payment receipt) need to reflect the client's brand: from address (client@theirdomain.com, not anything@wowcodes.in), email header logo, brand colours, and sign-off. These templates live in the script's email template directory and are straightforward to edit.
• Admin panel branding: The admin panel needs the same treatment as the public site — logo, colour scheme, and company name. Some scripts ship with a separate admin theme; check whether it inherits from the main CSS variables or has its own colour definitions.
• PWA configuration: If the script includes Progressive Web App support (BidKing does), update the PWA manifest file with the client's app name, short name, and icon assets. This determines how the app appears when installed on a user's home screen.
• Removal of "Powered by" notices: Any footer text, admin panel references, or public-facing credit notices pointing to WowCodes or BidKing need to be removed for a clean white-label. Under WowCodes' white-label arrangement, this is explicitly permitted — we don't require attribution on white-labelled deployments.

Technical steps

Here is the practical workflow from script purchase to client handover.

Step 1 — Set up version control. Fork the BidKing codebase into a private Git repository. Create a master branch that tracks the original script files (so you can merge upstream updates easily) and a client/[clientname] branch for all client-specific customisations. This structure makes update management tractable across multiple deployments.

Step 2 — Apply branding changes. In the client branch: update CSS variables for the client's colour palette, replace all logo and favicon assets, run a global find-and-replace on company and platform name strings, update email templates, and update the PWA manifest. Commit all changes with descriptive messages so you have a clear record of what was customised.

Step 3 — Configure the environment. Update the script's config file (typically .env or a dedicated config PHP file) with the client's domain, database credentials, SMTP settings (use the client's email domain), and any API keys. Never commit credentials to the Git repository — use environment variables or a gitignored config file.

Step 4 — Deploy to client's hosting. Deploy the client branch to the client's server or a server you manage on their behalf. Configure the domain's DNS to point to the server, install an SSL certificate (Let's Encrypt is free and handles automated renewal), and run the script's installation wizard to set up the database. Complete a full end-to-end test: registration, listing creation, bidding, payment, winner notification.

Step 5 — Hand over admin credentials. Deliver admin credentials to the client along with a brief admin guide covering the most common tasks: creating listings, managing users, processing payouts. A 30-minute screen-share walkthrough is worth more than a written guide for most clients.

Pricing the work

White-label auction platform projects have a well-defined cost structure that makes pricing straightforward.

• Script licence: $29–$59 for BidKing (Regular licence for internal use; Extended licence for public commercial platforms, priced separately by Envato).
• White-label customisation: 8–16 hours of developer time depending on the depth of branding customisation and any minor functional adjustments. At a $50–$100 hourly rate, this is $400–$1,600 in labour cost to you.
• Hosting setup: 1–2 hours including DNS configuration, SSL, and deployment. Often absorbed into the project fee or billed as a setup charge ($100–$200).
• Ongoing maintenance: Optional but recommended — a monthly retainer for updates, backups, and support. Standard range: $50–$200/month depending on platform activity.

Typical agency project total: $500–$2,000 for a complete white-label setup including the script licence, customisation, and initial deployment. Bill the client $1,500–$3,000 and you have healthy margin at either end of the range. The work scales well: your second white-label project takes half the time of the first because you've already built the workflow.

Managing multiple client deployments

Once you have more than two or three white-label auction clients, the operational complexity of managing independent deployments starts to compound. A few practices keep it manageable.

Version control strategy

Keep the master branch in your repository clean and in sync with the upstream BidKing releases. When WowCodes releases a script update, pull it into master first, review the changelog for anything that might conflict with your customisations, then merge from master into each client branch selectively. Client branches should contain only brand customisation changes — no functional changes that aren't in a separate, clearly labelled commit — so merges are clean and conflicts are minimal.

Update workflow

When a script update is available, your update workflow per client should be: pull update to staging environment, verify nothing is broken, deploy to production. Document the update in a change log per client so you have a record of what version each deployment is running. Bill clients for update time if your maintenance contract doesn't cover it — updates typically take 30–60 minutes per client deployment.

Support separation

You support the platform to the client. The client supports the platform to their users. Make this division explicit in your service agreement: your responsibility is that the software runs correctly; the client's responsibility is handling their users' questions, disputes, and requests. If the client's users have platform bugs to report, they go through the client to you — not directly to WowCodes or Envato.

When clients ask for custom features

Clients inevitably ask for features beyond the standard script. How you handle this determines whether your white-label practice is profitable or not.

BidKing ships with full PHP source code, which means any competent PHP developer can add features without constraints. This is the correct answer to give clients who ask whether customisation is possible: yes, and here's the scope and cost. Never promise custom features as part of the initial white-label engagement — scope them as separate projects with their own estimates.

Keep a change log per client that records every customisation applied to their deployment. This becomes critical during updates: you need to know exactly what was changed so you can verify those changes survive the update, or re-apply them if they don't. A client with 3 custom features after 6 months is a materially different deployment to manage than a stock white-label.

Building a recurring revenue model

White-label auction work is not just a one-time project fee — it's a platform for building recurring revenue that compounds over time.

The core recurring revenue streams for a white-label auction agency:

• Monthly hosting and maintenance: $50–$200/month per client covers server management, backups, security patches, and minor support requests. This is the baseline.
• Feature development retainer: Some clients want a fixed number of hours each month for ongoing improvements. A $500–$1,000/month retainer for 5–10 hours of development is common for active clients.
• Priority support tier: Offer a 4-hour response SLA for an additional $100–$200/month over standard support. Most clients won't need it — but the ones who do will pay for the peace of mind.

The maths compound quickly. A portfolio of 10 white-label auction clients generating $100/month each in maintenance fees equals $1,000/month in predictable recurring revenue — before any project or feature work. Ten clients at $150/month average is $1,500/month. At that scale, the recurring revenue from white-label maintenance alone covers a meaningful portion of overhead, making each new project fee nearly pure profit.

The other compounding factor: satisfied clients refer new clients. An agency with a proven white-label auction product and 5 successful client deployments on record has a compelling portfolio that sells future projects without a proposal. Prioritise doing excellent work on your first 3 deployments and the business development mostly handles itself.

Conclusion

White-label auction platform work is one of the highest-margin service categories available to a PHP-capable agency or freelancer in 2024. The combination of a $29–$59 script licence, 8–16 hours of customisation work, and a $1,500–$3,000 client project fee produces margins that pure bespoke development rarely matches — and the recurring maintenance model means each client relationship generates revenue indefinitely. The keys to doing it profitably: get the licence structure right from the start, build a clean version control workflow that makes updates tractable across multiple clients, and treat the maintenance retainer as a standard part of every engagement rather than an optional add-on. BidKing's CSS variable architecture and full source code access make it one of the cleanest scripts to white-label in the auction space — and WowCodes offers direct white-labelling arrangements that remove any ambiguity about what you can and can't do with the codebase.