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 project you can scope and price on your own terms. The script author sells more licences. Everyone wins.
Many scripts permit some degree of white-labelling — either under their standard licence terms or through a direct arrangement with the developer. If you plan to deploy BidKing under client branding, ask us about your specific requirements before you start.
The licence question
Before you modify a single file, you need to understand how the script's licence works — because getting this wrong creates legal exposure for you and your client.
BidKing used to be sold through CodeCanyon under Envato's licence terms. Today WowCodes sells it directly on startmymarketplace.com. A white-label deployment is a separate site for the client, and each licence covers a set number of sites, one per seat. Ask us if your setup is unclear.
Always clarify with the script author. Licence terms differ between products and sellers, so don't assume. If anything about your agency deployment is unclear — attribution, branding, how many sites you need to cover — chat with us on WhatsApp to confirm before you start.
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: In BidKing, upload the client's logo (with an optional dark-mode version) and browser icon in the admin under Settings › Branding — no file editing needed. Then check the public pages, the admin panel and the email templates to confirm the client's logo shows everywhere you expect.
- Colour scheme: Modern PHP scripts use CSS custom properties (variables) for colour theming. In BidKing you pick the store's Brand colour under Appearance › Themes, in its Colours section, as a preset or any colour code; it's used for buttons, links and highlights on every page. Deeper changes go in the theme's own
theme.css. - Company name throughout the platform: BidKing doesn't hardcode its product name in the PHP files — the store name shown in page titles, emails and the footer comes from the admin settings (Settings › General). Set the client's platform name there; no find-and-replace across the codebase is needed.
- Email templates: All transactional emails (registration confirmation, outbid notification, auction close, winner notification, payment receipt) need to reflect the client's brand: from address ([email protected], not [email protected]), email header logo, brand colours, and sign-off. In BidKing these templates are stored in the database and edited in the admin under Notifications › Templates.
- 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 (every BidKing edition does), check the app name and short name that appear when the app is installed on a user's home screen. In BidKing the manifest takes both from the store name in your settings automatically; the home-screen icons are fixed image files, not set from the admin.
- Removal of "Powered by" notices: Any public-facing credit notices need to be dealt with for a clean white-label. In BidKing, the licence badge can be hidden from Settings › General. If you have questions about attribution on a white-labelled deployment, ask us.
Technical steps
Here is the practical workflow from script purchase to client handover.
Step 1 — Plan where customisations live. BidKing updates itself from the admin with a one-click software update that replaces the core (kernel) files. Any edit you make directly to a core file will be overwritten by the next update. So keep every client-specific change out of the core: branding goes in the admin settings, visual changes go in a theme, and functional changes go in a plugin. Keep those theme and plugin files in your own private Git repository so you have a record of what each client has.
Step 2 — Apply branding changes. Set the client's store name, logos and browser icon in the admin settings, pick their Brand colour under Appearance › Themes, edit the email templates under Notifications › Templates, and hide the licence badge if required. Note what you changed for each client so you have a clear record of what was customised.
Step 3 — Configure the environment. BidKing's installation wizard writes the client's database details and licence to its .env file. Set the client's SMTP details (use the client's email domain) in the admin under Settings › Email (SMTP), and their payment gateway keys in the admin too. Never commit credentials or the .env file to the Git repository.
Step 4 — Deploy to client's hosting. Install the script, with the client's own licence, on 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: a one-time BidKing licence with a seat for each client site — see startmymarketplace.com for the current editions.
- White-label customisation: developer time depending on the depth of branding customisation and any minor functional adjustments, at your own hourly rate.
- Hosting setup: DNS configuration, SSL, and deployment. Often absorbed into the project fee or billed as a separate setup charge.
- Ongoing maintenance: Optional but recommended — a monthly retainer for updates, backups, and support, priced according to platform activity.
Add up the licence, your hours and any setup charge, and set your own price for the client on top of that. The work tends to get faster with practice: your second white-label project should go quicker than 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
Don't fork the core and merge upstream releases into client branches: BidKing's one-click software update replaces the core files, so a forked and edited core would be overwritten or drift out of step. Instead, keep each client's customisations in their own theme and plugins, and keep those in your private repository. Updates then replace the core cleanly while your customisations stay in place.
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.
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 still work after the update — which is much easier when they live in a theme or plugin rather than in edited core files. A client with 3 custom features after 6 months is a materially different deployment to manage than a stock white-label.
Practical tip: When a client requests a custom feature that seems broadly useful, consider scoping it as a contribution back to the main script (coordinate with WowCodes). If the feature gets incorporated into the main BidKing release, you no longer need to maintain it as a per-client customisation — reducing your ongoing maintenance burden.
Building a recurring revenue model
White-label auction work doesn't have to be a one-time project fee — it can also be the basis for ongoing client relationships.
The core recurring revenue streams for a white-label auction agency:
- Monthly hosting and maintenance: a monthly fee per client — set your own price — covering 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, priced as a monthly retainer.
- Priority support tier: Offer a faster response SLA for an additional monthly fee over standard support. Most clients won't need it — but some will value the peace of mind.
Recurring maintenance fees across several clients can make your income more predictable than project work alone — how much depends entirely on the prices you set and the clients you keep.
The other compounding factor: satisfied clients refer new clients. An agency with successful client deployments on record has a portfolio that helps sell future projects. Prioritise doing excellent work on your first few deployments.
Common questions
Can I white-label BidKing for clients?
Yes. Set the client's store name, logo and browser icon in the admin settings, pick their brand colour under Appearance › Themes, and hide the licence badge. No find-and-replace across the code is needed.
Do I need a separate licence for each client?
Not always. Each licence covers a set number of sites, one per seat; ask us if your setup is unclear.
Can I customise the code for a client?
Yes. BidKing ships with full PHP source code. Keep client changes in a theme or plugin rather than in edited core files, so updates don't overwrite them.
How should I charge for custom features?
Scope them as separate projects with their own estimates, rather than including them in the initial white-label setup, and keep a change log for each client.
Conclusion
White-label auction platform work lets a PHP-capable agency or freelancer deliver a production-ready platform far faster than bespoke development, starting from a one-time script licence and pricing the customisation and maintenance on your own terms. The keys to doing it well: get the licence structure right from the start (a licence seat for each client site), keep client customisations in themes and plugins so the one-click update stays clean, and treat the maintenance retainer as a standard part of every engagement rather than an optional add-on. BidKing's settings-driven branding, per-theme CSS variables and full source code access make it straightforward to white-label — and if you're unsure what you can and can't do with the codebase, ask us.