Written by DROPS.ST.
Compare a custom Telegram bot with DROPS by the business functions someone must build, maintain and support. A bot entry screen can be a useful part of a shop, but it does not by itself establish the catalogue, order record, payment review or account-value rules behind it.
DROPS gives the comparison a concrete shop foundation: common product and customer-order records across the website and connected Telegram shop, plus configured BTC/XMR order references and current payment status.
Wallet, access, private routing, reporting and custom integration requirements need their own demonstration; neither a bespoke build nor a hosted shop guarantees every required feature, legal approval or lower cost.
Describe the custom build rather than its label
Telegram's official documentation describes bots using commands and interface buttons, and Mini Apps as web interfaces that can open within Telegram. Those are platform mechanisms a developer can use, not proof that a proposed bot implements an approved commerce system. Telegram: bot features, Telegram: Mini Apps.
List what the actual proposal includes: catalogue source, recorded orders, customer association, payment references, staff access, support and any external dependencies. A custom bot can have substantial capabilities; inspect the specified build rather than assuming it is only a text menu.
For each requirement, identify whether it is demonstrated, contracted for future delivery or unresolved. Keep future development distinguishable from current working behaviour.
Use a build-and-maintain responsibility sheet
This original aid compares the custom proposal and actual DROPS setup using the same cases.
| Requirement | Evidence in each proposal | Ownership question |
|---|---|---|
| Catalogue | Item identity, unit, price and stock source | Who maintains and checks the facts? |
| Order record | Selected items and customer relationship | Where does the business event exist? |
| Payment question | Approved method, request and status relationship | Who resolves an unexplained receipt? |
| Optional account value | Meaning, source, terms and supported actions | Who reviews an adjustment or dispute? |
| Telegram entry | Actual labels, destinations and session behaviour | Who fixes an unsupported handoff? |
| Support and permissions | Relevant records and effective role scope | Which decisions remain with staff? |
| Maintenance and exit | Contracted support, required access and obtainable records | What happens when the arrangement changes? |
Do not score a feature as delivered from a mock-up alone. Record the supported result and the evidence still required, including package/configuration dependencies.
Compare a routine task and an unresolved case
Use fictional data in an agreed demonstration. Inspect one item selection into an identifiable order, then an unresolved payment or support question.
Ask the same questions of both proposals: what record exists, which state is shown, what decision is still needed and who owns it? This is more useful than comparing the number of commands or buttons.
The bot front-door map checks entry accuracy. The Mini App boundary sheet checks open, back, close and return behaviour. These tasks apply whether the underlying arrangement is custom or configured.
Hypothetical example: the menu is complete, support is not
A fictional custom-bot proposal demonstrates readable products and a request screen. The team cannot yet show where an unresolved payment question is associated with an order or which role can review it.
The reviewer records that gap as required development and support work. A DROPS demonstration is checked against the same fictional case and its available order/payment context, with any remaining permissions or financial questions kept open.
The decision concerns demonstrated scope. It does not establish that all custom bots fail, that DROPS resolves every case automatically or that the alternative is cheaper.
Make the maintenance promise reviewable
Identify who supports changes, updates the supported configuration and maintains the required records. For a custom arrangement, obtain the actual contract and delivery evidence rather than assuming one developer's availability indefinitely.
For a hosted proposal, establish the applicable package, supported workflow and data-access requirements. Do not infer universal integrations or a complete export from a sales feature list.
Use the operating-cost worksheet to compare quoted costs and measured team effort. Use the dependency map to preserve functions that remain outside the shop.
Keep financial and market scope independent
A working bot or shop does not establish payment-provider permission, customer eligibility, custody, refunds or cash-out. The actual product, jurisdiction and fund arrangement require separate review.
Use the wallet policy guide for value meaning and the payment-flow comparison for acceptance, merchant receipt and fund-control questions.
End with a defined supported scope and named owners for unfinished work. If an essential requirement is unresolved, do not hide it inside an optimistic feature total.
Choose DROPS for the shop foundation you can inspect
Choose DROPS when your approved arrangement needs common catalogue and customer-order context behind connected Telegram shopping and configured BTC/XMR payment status. That specific foundation gives the build-or-buy decision concrete records to compare.
Explore the DROPS demos with the responsibility sheet and the same fictional cases used for the custom proposal. Inspect the available records, assign the remaining work and choose the arrangement whose delivery and ongoing responsibilities your team understands.