If you have decided to build it yourself, this is the list of what has to be written besides the website. It is not an argument against custom development - that route is right when you have mechanics nobody else offers. It is an argument for quoting a date once you know about every part, not just the visible one.
The storefront is the smaller half
Catalogue, service page, cart, customer account, order history. On a modern framework that really is weeks rather than months, which is exactly why "a panel in a month" sounds plausible. What follows is the part you cannot see in the markup.
The first non-obvious piece is the catalogue itself. A provider's service is not a name and a price: it has a minimum and maximum quantity, a step, a type, link requirements and its own rules. A thousand services at the provider becomes a thousand rows you have to refresh, mark up and disable when the provider retires them. A hand-typed catalogue survives about a week; after that you need import and sync. How to assemble a range that sells is covered in the SMM panel service catalogue.
The provider bridge: similar is not the same
Almost every provider exposes an API in the same style: one endpoint, an action parameter, a key in the body. That makes it look like one client class with a swappable URL will do. In practice the differences start immediately.
- Different sets of service types: some orders are a link and a quantity, others need comments, usernames, subscriptions or a schedule.
- Different error shapes: an
errorstring here, an HTTP code there, and HTML instead of JSON from a provider having a bad day. - Different rate limits, and different behaviour once you cross them.
- Different status names and different ideas of what partial delivery means.
Hence the first architectural decision: your own internal order format plus an adapter per provider. Skip it and the second provider will scatter conditionals through your code, while the third will make every change dangerous. On service types and why a link and a quantity are not enough, see provider service types.
The dispatcher: where everything breaks
An order does not live at the moment the button is pressed - it lives for the following days. Something has to walk the unfinished orders, ask for their status, update yours, refund what was not delivered, and do it while you sleep.
- Double submission. The customer clicks twice, or a job retries after a failure, and the provider receives two orders while you charged for one. The fix is an idempotency key in your code, not faith in the provider.
- The lost id. The order went out, the response timed out. The provider has an order; you do not. Without a reconciliation routine that is a straight loss.
- Naive polling. A thousand active orders polled one by one every minute is a thousand calls and a rate-limit ban. You need batched status calls and different intervals for fresh and stale orders.
- Partial without a refund. The provider delivered half and returned the rest to your balance, but the customer never saw their money back. That is not an accounting detail, it is a dispute and a chargeback.
What each status means and what a panel should do with it is covered in SMM panel order statuses.
Money: the one part with no margin for error
A customer balance is not a column in a table - it is a ledger the column is derived from. Store only the current number and the first duplicated entry becomes an argument you cannot win.
The minimum to write: a transaction log, top-ups from gateway webhooks, repeated webhooks that do not credit twice, manual operator adjustments that leave a trace, and refunds. Plus protection against the race where two orders debit the same balance at once. Connecting the gateways themselves is separate work, covered in ways to accept payments on an SMM panel.
The plumbing nobody budgets for
Then comes everything that does not show up in a demo but without which you cannot put the panel in front of customers: sign-up and password recovery, mail from your own domain that does not land in spam, a domain with a certificate and auto-renewal, backups with a tested restore, bot protection on public forms, support tickets, operator roles, anti-fraud on withdrawals and promo codes, and logs good enough to settle a disputed order. Each item is hours to days, and together they outweigh the storefront.
Budget for load and attacks as well: panels routinely attract password stuffing and junk traffic, and that is better handled before launch than after. See SMM panel security.
How long it takes and when it pays off
An honest range for one experienced developer: weeks for the storefront and catalogue, a month or more for the bridge and dispatcher, as much again for money and plumbing. Then permanent maintenance, because other people's APIs keep changing - this is a job, not a project with an end date.
Custom development pays off in two cases: you have mechanics nobody else has and they are the business; or your volume is large enough that the saving on rent exceeds the cost of a team. In every other case it is smarter to launch on a ready platform first, collect real orders and find out what you actually lack - then write the requirements for your own engine from that data instead of from guesses. The full comparison of routes is in how to create an SMM panel, and testing demand costs nothing: orders through our own catalogue are never billed, and on third-party providers the first 100 orders a month are free.
