It was born early.

Most of it emerged when the Go runtime was younger, the compiler less aggressive, and the garbage collector far more sensitive to allocation patterns. Over time, the runtime evolved — but the advice stayed frozen.

This article is not about replacing one list of rules with another.
It’s about verifying which intuitions still hold in modern Go, and which ones quietly stopped matching reality.

Instead of arguing, we’ll measure.

Allocation vs Lifetime: The Core Misunderstanding

The most persistent performance instinct in Go is the fear of heap allocations.

The intuition feels solid: stack allocations are cheap, heap allocations are expensive, garbage collection is costly. Therefore, avoid heap allocations.

That logic collapses once you separate allocation cost from object lifetime.

In modern Go, allocating an object on the heap is usually cheap. Keeping it alive is not.

Let’s start with the simplest possible benchmark: allocating short-lived heap objects versus doing nothing special at all.

Benchmark: Short-Lived Heap Allocation

package main

import "testing"

var sink int

func allocShortLived(n int) {
    s := 0
    for i := range n { // modern: range over int
        x := new(int)
        *x = i
        s += *x
    }
    sink = s // escape to global to prevent elimination
}

func BenchmarkShortLivedAlloc(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        allocShortLived(1024)
    }
}

func noAlloc(n int) {
    s := 0
    for i := range n {
        x := i
        s += x
    }
    sink = s
}

func BenchmarkShortLived_NoAlloc(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        noAlloc(1024)
    }
}

Despite using new(int), the benchmark reports 0 allocations per operation. This means the compiler was able to keep the allocated value on the stack (or eliminate the allocation entirely) because the pointer never escaped.

In modern Go, using pointers does not automatically imply heap allocation. Allocation location is a compiler decision based on escape analysis, not syntax.

Why Preallocation Became a Cargo Cult

Preallocating slices is one of the most common “optimizations” people apply reflexively.

The reasoning is simple: slice growth reallocates memory, reallocation is expensive, therefore we should always preallocate.

That reasoning breaks down when the preallocation guess is wrong — which is most of the time in real systems.

Let’s compare three cases: no preallocation, exact preallocation, and aggressive over-preallocation.

Benchmark: Slice Growth Strategies

package main

import "testing"

const sliceN = 256

// sinks prevent compiler from eliminating work.
var sinkSlice []int
var sinkInt int

func buildNoPrealloc(n int) []int {
    var out []int
    for i := range n { 
        out = append(out, i)
    }
    return out
}

func buildExactPrealloc(n int) []int {
    out := make([]int, 0, n)
    for i := range n {
        out = append(out, i)
    }
    return out
}

func buildOverPrealloc(n int) []int {
    // Intentionally over-allocating to simulate a common "just in case" optimization.
    out := make([]int, 0, n*16)
    for i := range n {
        out = append(out, i)
    }
    return out
}

func BenchmarkSlices_NoPrealloc(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        s := buildNoPrealloc(sliceN)
        // touch result so it can't be optimized away
        sinkInt += len(s)
        sinkSlice = s
    }
}

func BenchmarkSlices_ExactPrealloc(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        s := buildExactPrealloc(sliceN)
        sinkInt += len(s)
        sinkSlice = s
    }
}

func BenchmarkSlices_OverPrealloc(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        s := buildOverPrealloc(sliceN)
        sinkInt += len(s)
        sinkSlice = s
    }
}

Exact preallocation is the “good” case here: it cuts allocations from 9 to 1, halves B/op, and reduces runtime from ~1050 ns/op to ~410 ns/op. No prealloc triggers slice growth and multiple reallocations (9 allocs/op), which is exactly the kind of overhead preallocation is meant to avoid.

The interesting part is over-preallocation. It still performs only 1 allocation, but it allocates far more memory (32 KB/op) and becomes significantly slower (~4.5 µs/op typical). This doesn’t mean “over-prealloc is always bad” — it means that allocating far more capacity than you’ll use can increase memory traffic and hurt cache behavior, even when allocation count looks great.

In modern Go, allocation count alone is a poor proxy for performance — bytes allocated and object lifetime often matter more.

Interfaces: The Optimization That Rarely Pays

Another long-standing belief is that interface calls are inherently slow and should be avoided in performance-sensitive code.

This belief comes from a time when interface dispatch blocked inlining and added measurable overhead.

Modern compilers are far more capable.

Let’s measure the difference between concrete calls, interface calls, and generic dispatch.

Benchmark: Interface vs Concrete vs Generic

package main

import "testing"

type Adder interface {
    Add(int) int
}

type impl struct {
    base int
}

func (i impl) Add(x int) int {
    return i.base + x
}

func callConcrete(v impl, n int) int {
    sum := 0
    for i := range n {
        sum += v.Add(i)
    }
    return sum
}

func callInterface(v Adder, n int) int {
    sum := 0
    for i := range n {
        sum += v.Add(i)
    }
    return sum
}

func callGeneric[T interface{ Add(int) int }](v T, n int) int {
    sum := 0
    for i := range n {
        sum += v.Add(i)
    }
    return sum
}

func BenchmarkConcrete(b *testing.B) {
    b.ReportAllocs()
    v := impl{base: 10}
    for b.Loop() {
        _ = callConcrete(v, 1024)
    }
}

func BenchmarkInterface(b *testing.B) {
    b.ReportAllocs()
    v := impl{base: 10}
    for b.Loop() {
        _ = callInterface(v, 1024)
    }
}

func BenchmarkGeneric(b *testing.B) {
    b.ReportAllocs()
    v := impl{base: 10}
    for b.Loop() {
        _ = callGeneric(v, 1024)
    }
}

This benchmark isolates dispatch overhead in a tight loop — no allocations, no I/O, no cache-heavy data structures. In this artificial setting, interface and generic dispatch are ~6× slower than a direct concrete call (~1.6 µs vs ~0.28 µs per 1024 iterations), while still producing 0 allocs/op.

The point is not “interfaces are free” — they aren’t. The point is that this overhead is purely call-level and often disappears inside real workloads where time is dominated by memory access, synchronization, syscalls, or network I/O.

So the modern rule is: interfaces can cost something, but optimizing them is rarely the first place you get meaningful wins — measure before reshaping your APIs.

Note: this generic benchmark uses a method constraint, which may still compile to indirect calls depending on how the compiler specializes the instantiation.

sync.Pool: When the Cure Becomes the Disease

sync.Pool is often introduced as a way to “reduce GC pressure”.

That framing is misleading.

sync.Pool is designed to improve throughput by opportunistically reusing short-lived objects. It is explicitly allowed to drop its contents at any time.

Let’s compare direct allocation with pooled reuse.

Benchmark: Allocation vs Pool Reuse

package main

import (
    "sync"
    "testing"
)

var bufPool = sync.Pool{
    New: func() any {
        b := make([]byte, 32*1024)
        return &b
    },
}

func allocBuffers(n int) {
    for i := range n {
        b := make([]byte, 32*1024)
        b[0] = byte(i)
    }
}

func poolBuffers(n int) {
    for i := range n {
        p := bufPool.Get().(*[]byte)
        b := *p
        b[0] = byte(i)
        bufPool.Put(p)
    }
}

func BenchmarkAlloc(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        allocBuffers(128)
    }
}

func BenchmarkPool(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        poolBuffers(128)
    }
}

In this benchmark, sync.Pool is dramatically slower than plain allocation: ~1.7 µs/op versus ~41 ns/op. The key detail is that both variants report 0 allocs/op, which means the compiler was able to eliminate the allocation work in the “Alloc” case (and the pool path is mostly measuring Get/Put synchronization and bookkeeping overhead).

This is a good reminder that sync.Pool is not a universal “make things faster” switch. In microbenchmarks where allocations don’t actually hit the heap, a pool can easily be pure overhead.

This benchmark intentionally represents a case where allocations do not escape to the heap, making it a worst-case scenario for sync.Pool.

Retention: The Cost That Actually Hurts

The most expensive performance bugs in modern Go are rarely about how fast memory is allocated.

They are about how long memory stays reachable.

Let’s compare two patterns: retaining large payloads vs extracting only what’s needed.

Benchmark: Memory Retention

package main

import "testing"

var sink2 [][]byte

func badRetention(n int) [][]byte {
    out := make([][]byte, 0, n)
    for range n {
        b := make([]byte, 64*1024)
        out = append(out, b)
    }
    return out
}

func goodRetention(n int) [][]byte {
    out := make([][]byte, 0, n)
    for range n {
        b := make([]byte, 64*1024)
        out = append(out, append([]byte(nil), b[:64]...))
    }
    return out
}

func BenchmarkBadRetention(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        sink2 = badRetention(128)
    }
}

func BenchmarkGoodRetention(b *testing.B) {
    b.ReportAllocs()
    for b.Loop() {
        sink2 = goodRetention(128)
    }
}

Both benchmarks perform the same number of allocations (129 allocs/op). The difference is not how many objects are allocated, but how much memory they retain.

In the “bad retention” case, each iteration keeps references to large payloads, resulting in ~8 MB of live memory per operation and a runtime of ~1.5 ms/op. In the “good retention” case, the same number of allocations is performed, but only a small slice of each payload is retained, reducing live memory to ~11 KB and execution time to ~90 µs/op.

This is a ~16× difference in runtime with identical allocation counts.

This benchmark demonstrates why modern Go performance issues are rarely about allocation count. Both cases allocate the same number of objects, yet their performance differs by an order of magnitude. What matters is retention: how much memory stays reachable and for how long.

Reducing allocs/op without controlling object lifetime often optimizes the wrong thing.

The Real Shift in Modern Go Performance

What changed by Go 1.25 is not a single feature or trick. The bigger shift is that many mechanical costs got cheaper, so architectural costs now dominate the profile.

Modern Go rewards designs with clear ownership and short-lived data. When lifetimes are explicit and concurrency is bounded, the runtime has much less “mess” to manage, and optimizations become predictable.

Old advice often assumed the runtime was fragile. In modern Go, the runtime is usually fine — it’s unclear lifetimes and accidental retention that break performance.

Closing Thought

If you optimize before measuring, you are probably optimizing a version of Go you are no longer running.

Let the runtime handle mechanics.

Your responsibility is to design systems whose data does not outlive its usefulness.

And just as often, the question itself is slightly wrong.

In Go, stack vs heap is not a manual decision — it’s a result of escape analysis, and misunderstanding this leads to performance myths and unnecessary micro-optimizations.

If you’ve ever profiled a Go program and wondered why a simple function allocates memory, or why a tiny struct suddenly ends up on the heap, you’ve seen the effects of escape analysis. Beginners often learn stack and heap as if they were fixed rules — small things go on the stack, large things go on the heap — but Go doesn’t work like that at all. Size is irrelevant. What matters is lifetime.

A value stays on the stack only if the compiler can prove it never outlives the function that created it. The moment the lifetime becomes ambiguous, that value “escapes,” and Go places it on the heap. This is not a heuristic and not guesswork; it is a strict safety rule.

Understanding this rule gives you x-ray vision into your Go programs. You start predicting allocations before they happen. You see how small changes in code shape memory behavior. And most importantly, you learn to write Go the way the compiler expects — which results in faster, cleaner, more predictable programs.

Let's walk through this from the ground up.

What This Article Focuses On

This article is not about forcing allocations onto the stack or the heap.

It explains how Go’s escape analysis works, why certain values escape, and why trying to “outsmart” the compiler usually backfires.

The Stack: Fast, Local, Temporary

A stack frame exists only during the execution of a function. When the function returns, the frame disappears. If a value can be proven to stay within that frame, it is stack allocated.

A simple example:

func sum(a, b int) int {
    c := a + b
    return c
}

If we ask the compiler to show escape analysis:

$ go build -gcflags="-m"
<no escape>

Nothing escapes. Everything is on the stack. The compiler is even free to inline the function, meaning the variables may never exist as “variables” at all — they become registers or constants.

This is the ideal path: pure stack behavior, no GC pressure, no heap work.

The Heap: For Values with Extended Lifetime

A value must live on the heap if something outside the current stack frame needs to reference it. Returning a pointer is the most common example:

func makePtr() *int {
    x := 42
    return &x
}

Compiler output:

./main.go:4:9: &x escapes to heap

This has nothing to do with the size of x. The compiler simply sees that the caller needs a reference to x after the function returns. The stack frame cannot hold it anymore.

A beginner often doesn’t realize that the pointer itself is not expensive — it’s the lifetime extension that forces the escape.

Closures: When Variables Quietly Escape

Closures are a classic place where beginners accidentally create heap allocations.

func counter() func() int {
    x := 0
    return func() int {
        x++
        return x
    }
}

Compiler output:

./main.go:6:13: func literal escapes to heap
./main.go:5:5: moved to heap: x

Why? Because the returned function continues to exist after counter finishes. It needs access to x. Therefore, x must move to the heap, where its lifetime is no longer tied to the stack frame.

Many beginners write closure-based code without realizing they are allocating memory every time.

Two Constructors, Two Lifetimes, Two Allocation Patterns

This is one of the clearest ways to see escape analysis in action.

Version 1 — returning a value:

type User struct {
    Name string
}

func newUser(name string) User {
    return User{Name: name}
}

And now version 2 — returning a pointer:

func newUserPtr(name string) *User {
    return &User{Name: name}
}

For the first version, the compiler often places User directly into the caller’s stack frame. For the pointer version, the allocation must occur on the heap.

Same data. Same fields. Same size. Different lifetime = different memory behavior.

This is why experienced Go developers say: prefer returning values unless you need shared mutable state.

Escape Analysis Loves Clear Ownership

Here’s a subtle example where a tiny rewrite prevents a heap escape:

func sumSlice(nums []int) *int {
    total := 0
    for _, v := range nums {
        total += v
    }
    return &total
}

Compiler:

./main.go:7:12: &total escapes to heap

But if we write it like this:

func sumSlice(nums []int) int {
    total := 0
    for _, v := range nums {
        total += v
    }
    return total
}

Now:

<no escape>

Exact same logic. Different lifetime semantics.

This is the power of understanding escape analysis: your intuition becomes aligned with the compiler.

A Surprising Case: Heap Allocations Without Pointers

Sometimes a heap escape happens even though you don’t return a pointer. A classic example:

func run() {
    for i := 0; i < 3; i++ {
        go func() {
            fmt.Println(i)
        }()
    }
}

Compiler:

./main.go:5:10: func literal escapes to heap
./main.go:4:6: moved to heap: i

Why? Because the goroutine runs after the loop iteration completes. It needs access to i. Therefore i cannot live on the stack.

This is the precise moment when a beginner realizes that concurrency also changes lifetimes.

What Escape Analysis Is Actually Doing

It’s not trying to optimize your code. It’s proving safety.

If the compiler can prove a value is local → stack. If it cannot prove → heap.

It’s a conservative algorithm. A value will escape even when theoretically safe, simply because proving otherwise would require solving undecidable problems. Go plays it safe; that’s what keeps programs correct.

How to See Escape Analysis in Your Code

You can observe everything the compiler decides:

go build -gcflags="-m=2"

Or for even more detail:

go build -gcflags="-m -m"

This becomes addictive. You begin scanning your code and predicting escapes before the compiler prints them.

Once you reach that level, Go feels like a language that explains itself to you.

Why This Matters for Beginners

Understanding escape analysis is not about premature optimization. It’s about forming the mental model that Go expects you to have.

Once you understand lifetimes:

– you choose value vs pointer intentionally – you design APIs that minimize hidden allocations – your code scales better under load – you avoid concurrency pitfalls – you become predictable to the compiler

This is exactly where beginners stop being beginners.

Want to go further?

This series focuses on understanding Go, not just using it.
If you want to continue in the same mindset, Educative is a great next step.

It’s a single subscription that gives you access to hundreds of in-depth, text-based courses — from Go internals and concurrency to system design and distributed systems. No videos, no per-course purchases, just structured learning you can move through at your own pace.

👉 Explore the full Educative library here

There comes a point in the life of any backend system when it stops feeling like code and starts feeling like something alive. It develops rhythm. It inhales traffic and exhales processed results. It has quiet, sleepy nights and sudden bursts of frantic activity. There are pulses, irregular waves, unpredictable spikes. And somewhere along the way you realize: your service no longer “handles events.” It lives inside their flow.

When this shift happens, technical problems change. The bottlenecks no longer hide inside functions; they appear in the intervals between them. Throughput becomes secondary. The real enemy is mismatch — between how fast the world pushes events into your system, and how fast your system can actually understand, transform, and persist them.

This is the moment when system design becomes the real engineering challenge.

When the system breaks for the first time

Most pipelines start small. A simple handler, a simple queue, a simple database write. It works well enough that nobody touches it. It works so well that people forget how fragile it is.

Then one day traffic spikes — maybe because of a marketing blast, maybe because a partner system retries aggressively, maybe because a batch job upstream flushes a backlog all at once. Suddenly your queue begins to swell. Latency stretches. The consumer falls behind. Retries multiply until they create more load than the original traffic.

The pipeline stops flowing and starts drowning.

This is the first real lesson of high-load event systems:

they fail not because the code is slow, but because the flow becomes unmanageable.

The shape of real traffic

No real system receives a steady, comforting stream of events. Traffic arrives in waves — sometimes elegant and predictable, often messy and violent. Humans behave in bursts. Networks behave in bursts. Distributed retries behave in violent, chaotic bursts.

You cannot “smooth out” these patterns.

A resilient pipeline accepts that the world is uneven and builds space for chaos to exist safely.

That space usually takes the form of a queue — not as an architectural choice, but as a survival mechanism. The queue becomes a buffer between the storm of incoming events and the calmer process of turning them into something meaningful.

Queues as lungs

In a healthy high-load system, the queue behaves like a pair of lungs. It allows the pipeline to inhale more than it can immediately process, and exhale steadily at a rate it can sustain.

Kafka and Redpanda became industry standards not because of trendiness, but because of how gracefully they handle irregularity. They accept spikes without panic. They distribute load. They replay. They hold the line.

Once your Go service reads from Kafka, it stops worrying about the pace of incoming events. The spike has already been absorbed upstream. The only remaining question is: How fast can you work through them?

This moment — when ingestion is decoupled from processing — is the first real structural victory.

The art of consumption

Most pipelines break not in the queue, but in the consumer.

A consumer is not simply a loop that reads messages. It is a balancing act between the volatility of the outside world and the steadiness of your processing layer. Bad consumers spawn thousands of goroutines. They block on slow external APIs. They freeze when downstream systems degrade. They try to do too much at once, or not enough. They behave impulsively.

Good consumers are almost biological in their discipline. They take messages in small, digestible batches. They know their limits. They adjust their pace when downstream systems slow down. They treat failures as routine, not emergencies. They avoid unbounded concurrency. They understand idempotency as a fundamental requirement, not a luxury.

A good consumer behaves less like a function and more like a living system that maintains homeostasis.

Processing: where optimism dies

Processing is the most fragile stage of the pipeline because it touches the outside world. It calls APIs that may freeze, databases that may stall, caches that may expire at the wrong moment. It transforms data that may be malformed. It tries to enforce consistency in a world that refuses to be consistent.

A pipeline that assumes everything will be fast and successful is doomed. A resilient pipeline assumes:

• failures are normal

• retries are inevitable

• latencies fluctuate

• dependencies degrade

• storage hesitates

• the system must remain stable through all of it

This is why mature pipelines use retry budgets, circuit breakers, local caching, dead-letter queues, asynchronous writes, and write-behind patterns. Not because they sound architecturally pretty, but because systems without them eventually collapse.

Storage: a tide, not a constant

Every event eventually needs to land somewhere — a database, an index, a log archive. But storage systems have their own personalities. They slow down unexpectedly. They warm up slowly. They behave differently under different load profiles.

A pipeline that writes synchronously into storage is a pipeline chained to its slowest component.

A pipeline that buffers, batches, and isolates storage writes is a pipeline that can keep breathing even when the datastore has a moment of weakness.

Backpressure as the foundation of survival

Modern systems rarely die from too little throughput. They die from too much. A system that cannot say “no” becomes a hostage of its own good performance.

Backpressure gives the pipeline the ability to decline work — politely, intentionally, and safely. It prevents cascades of failures. It enforces boundaries. It makes the system self-aware.

Backpressure is not a feature; it is a nervous system.

What Go adds to the equation

Go is unusually well-suited for event-driven pipelines. Not because it is the fastest language, but because its concurrency model maps naturally onto the idea of flow. Goroutines give us lightweight execution. Channels give us decoupling. Context gives us cancellation. Worker pools give us shape and boundaries.

But Go won’t save you from systemic mistakes. Unbounded concurrency will still drown you. Missing timeouts will still destroy you. Poor storage design will still block you. Misbehaving consumers will still collapse under load.

Go gives you tools — not immunity.

When the system finally breathes

A well-designed pipeline doesn’t feel fast; it feels calm. It doesn’t panic when traffic spikes; it absorbs. It doesn’t stall when an external system slows down; it adapts. It doesn’t cascade on failure; it isolates, retries, and moves on.

This calmness is the true mark of good system design.

A high-load event pipeline is not the one that processes the most events per second, but the one that maintains rhythm under pressure.

When your system starts breathing — steadily, predictably, effortlessly — that’s when you know the architecture is finally right.

What’s This All About?

Telegram Mini Apps are those slick little web apps that live inside Telegram bots—think interactive menus, mini-games, or order trackers. They’re awesome, but getting started? Not so much. You’ve got to juggle a frontend, a backend, a database, and deployment, all while praying it plays nice with Telegram. That’s where TMA Starter Kit comes in.

It’s a pre-built, batteries-included foundation: a modern frontend, a lightweight backend, and DevOps goodies, all wired up and ready to roll. The goal? Cut the setup grind so you can focus on coding the cool stuff.

Why Bother with TMA Starter Kit?

I’ll level with you—building a TMA from scratch is a slog. You’re googling Vue.js configs, wrestling with Go routing, and cursing Docker networking before you even write a single feature. This kit skips the nonsense. Here’s what it brings to the table:

• Zero-to-Running in Minutes: Clone it, run a Docker command, and boom—you’ve got a full app stack.

• Solid Tech Choices: Quasar (Vue.js) with TypeScript, Go for the API, and MongoDB—tools you’ll actually enjoy using.

• Docker Magic: Everything’s containerized. No “works on my machine” excuses here.

• Telegram-Ready: Clear steps to hook it into a bot and go live.

• Hackable: Modular setup means you can tweak it to fit your vibe.

The Stack Breakdown

Here’s how it’s pieced together—clean, simple, and purposeful:

• frontend/: Powered by Quasar (Vue.js) with TypeScript and the Composition API. It’s where your Mini App’s UI lives—responsive, fast, and perfect for Telegram’s in-app vibe.

• backend/: A Go API that’s lean and mean. Handles your logic, talks to the frontend, and scales like a champ.

• devops/: Docker Compose files and CI/CD bits to keep it all humming. Spin up the whole stack with one command.

It’s all glued together with Docker, so whether you’re on a Mac, Linux, or that sketchy Windows laptop, it just works.

How Do You Use It?

Okay, let’s get practical. Here’s the quickstart:

1. Fire It Up:

    docker compose -f devops/docker-compose.dev.yml up -d
   

   This launches the frontend (port 9000), backend, and MongoDB in containers. Done.

2. Expose It: Install localtunnel (npm i -g localtunnel), then:

    lt --port 9000 --subdomain my-cool-tma
   

   You’ll get a public URL like https://my-cool-tma.loca.lt.

3. Telegram Time:

   • Hit up @BotFather, make a bot with /newbot.

   • Use /setmenu to link your localtunnel URL.

   • Open your bot, tap the menu, and voilà—your Mini App’s live.

Total time? Maybe 10 minutes if you’re sipping coffee slowly.

Who’s This For?

• Prototypers: Got a bot idea? Test it before dinner.

• Side Hustlers: Building a client app? Ship it fast and look pro.

• Tinkerers: New to TMA or modern stacks? Play around and learn.

A Real Example

Picture this: you’re coding a bot to track coffee orders for your team. With TMA Starter Kit:

• Quasar frontend whips up a form in an hour.

• Go backend saves orders to MongoDB with a few lines.

• Docker and localtunnel get it online, and Telegram’s hosting your app by noon.

From scratch? You’d still be debugging CORS errors. Trust me, I’ve been there.

Why I Built It (and Why You Might Care)

I’m a sucker for Telegram’s ecosystem—it’s huge, engaged, and ripe for innovation. But every time I started a TMA, I wasted hours on boilerplate. So, I made this kit to scratch my own itch. If you’ve ever felt that setup pain, it might scratch yours too.

Give It a Spin

TMA Starter Kit isn’t some polished product—it’s a practical starting point, rough edges and all. Clone it, break it, make it yours. If you build something cool (or find a bug), hit me up—I’d love to hear about it.

Check it out on GitHub

Happy coding, Hashnode fam! Let’s build some killer Telegram apps together.