Skip to main content
T TON Adoption
Basics GUIDE · 2026

TON Development Company: How to Hire in 2026

A practical buyer's guide to hiring a TON development company or freelancer: what services exist, how to vet audits and portfolios, typical scope, red flags…

Author
TON Adoption Team · research desk
Published
6 min read

You have decided to launch something on TON: a Telegram mini-app, a jetton with its own economy, a bot that accepts payments, or some DeFi mechanic. You do not have an in-house team, and the question is simple: who do you hand the job to, and how do you avoid a bad choice. This piece is about hiring, not about code. If you need a technical build guide, start with the FunC vs Tact breakdown. Here we cover how to evaluate and hire a TON development company in 2026.

What services actually exist

TON is not one type of work but several distinct competencies. Before you start looking for a vendor, understand what you actually need. A contractor who writes great bots will not necessarily write safe smart contracts, and vice versa.

Smart contracts

This covers jettons (tokens following the TEP-74 standard), NFT collections, escrow, vesting, staking logic, and DeFi primitives. They are written in FunC, Tact, or Tolk. This is the highest-stakes part: a bug in a contract is irreversible after deployment and can cost users money. Here experience and an audit matter far more than speed.

Telegram mini-apps

A web app inside Telegram, usually wired to a wallet through TON Connect. This needs frontend (React/Vue plus the Telegram WebApp SDK), blockchain integration, and often a backend. If you are unsure what these are and how they work, see our overview of mini-apps.

Bots and payments

Telegram bots that accept TON or USDT, P2P logic, notifications. This is the most mature and predictable part of the market, and we have a dedicated guide to accepting TON in a business bot.

Turnkey jetton launches

A separate category: token plus liquidity plus a basic site plus a bot. This area has an unusually high number of weak vendors, because demand is high and the barrier to entry looks low.

Typical scope and timelines

To speak the same language as a contractor, keep rough reference points in mind. These are not prices, just orders of magnitude. Real timelines depend on a dozen factors.

Type of workComplexity tierWhat is critical
Bot that accepts paymentsLowWebhook reliability, idempotency
TEP-74 jettonLow to mediumMetadata correctness, admin rights
Mini-app with a walletMediumUX, TON Connect, backend accounting
Custom smart contractHighSecurity, audit, tests
DeFi protocolVery highAudit, formal verification, monitoring

The sane principle: the more money flows through your code, the more time should go into tests and an audit, not into features.

How to vet a contractor

The most common mistake is trusting the deck. The TON market has plenty of studios that produce beautiful sites but have not deployed a single contract. Verify on substance.

A portfolio you can actually open

Ask for links, not screenshots: contract addresses on Tonviewer or Tonscan that you can open and see transactions in; live mini-apps that launch right now; a GitHub with real commit history, not a single “initial commit” from yesterday. If a contractor cannot show one real on-chain address, that is a warning sign for smart-contract work.

Audits

If you are talking about a contract that holds funds, ask: have you done projects with an external audit? Which firm audited it? Can I see the report? An honest “we have not had audits, but for your project we recommend this auditor” is better than a vague “everything we do is secure.” Never accept “security” as a claim without evidence.

A technical conversation

Even if you are not a programmer, ask the contractor to explain in plain terms: what is irreversible after deployment, how they test contracts, and what happens if the contract needs to be upgraded. Clear answers about upgradeability, testnet, and error handling separate a professional from someone who generated a jetton from a template once.

In-house, agency, or freelancer

Three models, each with its own sweet spot.

Freelancer. Cheap and fast on isolated jobs: one bot, one jetton, a simple mini-app. The risk is the person vanishing mid-project and the lack of support. You mitigate it with a tight spec, milestone-based payment, and pushing code into your repository from day one.

Studio or agency. Process, staff backup, post-delivery support. More expensive, sometimes slower to start because of management overhead. Worth it for projects where continuity matters and the code will live and evolve.

In-house team. Justified when TON development is the core of your business, not a one-time launch. Expensive to maintain, but it gives full control and builds expertise internally.

A practical hybrid: hire a studio for the first launch on condition of full code and documentation handover, then decide whether to hire your own developer for maintenance or extend the contract.

Red flags

A few signals that should make you cautious:

  • A guaranteed return or token “moon.” Anyone who promises your jetton’s price will rise is either incompetent or a scammer.
  • Not a single contract in the explorer. For smart-contract work this is disqualifying.
  • Refusal to hand over source. Code you pay for should be yours. Vendor lock-in through a closed repository is a trap.
  • “You do not need an audit” by default. For a money-handling contract this is irresponsible.
  • A flat turnkey price with no scope. A fixed price without a scope breakdown usually hides either overpayment or a trimmed-down deliverable.
  • Messenger only, no contracts. With no legal record of milestones and code ownership you are defenseless.

RFP checklist: what to send a contractor

To get comparable proposals from different vendors, send everyone the same request (an RFP). The minimum set:

  1. Product goal — what the user does and why, in one paragraph.
  2. Type of work — contract / mini-app / bot / combination.
  3. What the code holds — does it custody funds, what amounts are expected.
  4. Audit requirements — is an external audit needed, is there a budget for it.
  5. Integrations — TON Connect, a specific wallet, a payment provider, a backend.
  6. Code handover — the repository is yours, documentation is mandatory.
  7. Milestones and acceptance — how you split the work and the criterion for accepting each stage.
  8. Support — what is included after delivery and for how long.
  9. Timeline — your target date and how flexible it is.

A good proposal in return should include a milestone breakdown, explicit assumptions, a mention of tests, and (for money-handling contracts) an audit recommendation. If all you get back is a number and “we will do it in a week,” that is a cue to ask more questions, not to sign.

Bottom line

Choosing a TON contractor is not a hunt for the lowest price; it is risk management. The more money that flows through the code, the more experience, audits, and a legal record matter. Verify portfolios by on-chain addresses, not by slides; insist on source handover from day one; never accept “security” without evidence. A well-built RFP and healthy skepticism toward return promises will filter out most weak vendors before the first payment.

Frequently asked

The range is wide. A simple Telegram payment bot is at the low end, a typical mini-app with jetton logic is mid-range, and a full DeFi protocol with an audit runs into the high tens of thousands and up. Only a scoped estimate against your actual requirements gives a real number, not a price on a studio's homepage.
If the contract holds other people's money, yes, always. An audit is cheaper than losing user funds and reputation. If the contract stores nothing (for example a purely accounting jetton with no admin powers), an internal review plus tests may be enough, but make that call deliberately.
A freelancer is cheaper and faster on small jobs but riskier on long projects. A studio gives you process, staff backup, and support, but costs more. In-house makes sense when development is the core of your product, not a one-off task.
Ask for deployed contract addresses you can open in an explorer, a GitHub with real commit history, and links to live mini-apps. Genuine experience shows up in on-chain addresses and transactions, not in pretty slides.

Related