Seeing the Traffic & Teaching Functory to Price Itself

The problem

Functory was flying half-blind.

The product was evolving fast, but there was no clear view of where traffic came from, which pages actually converted, or which features people touched before bouncing.

At the same time, the backend had accumulated just enough complexity to make every new billing-related change feel a bit risky.

On top of that, pricing still relied heavily on manual guesses:

Creators had to pick a number without much guidance.
The platform had microtokens and tiers, but no real "brain" to suggest good defaults.

If Functory wants to be the place where people just upload a function and get on with their lives, it needs two things:

Clear visibility on what users do.
A pricing layer that helps, instead of getting in the way.

What shipped

Three foundations to make the next steps easier and smarter:

1. GA4 integration for real product analytics

Added Google Analytics 4 to the frontend so Functory can finally see where visitors come from and how they move through key paths.
Started tracking core events (landing, signup, catalog exploration, function pages) to understand which flows actually work.
Laid the groundwork for later funnels, cohorts, and experiments without turning the UI into an analytics dashboard.

2. A cleaner backend surface

Refactored internal modules around billing and core services to be easier to reason about.
Reduced some of the “historical” coupling that made pricing changes scarier than they needed to be.
The goal isn’t to rewrite everything — just to make the most critical pieces boring, predictable, and testable.

3. First steps toward automatic pricing

Started wiring a pricing layer that can infer sensible defaults from a function, instead of asking creators to invent numbers from scratch.
The idea: combine hardware tier, expected run time, and platform constraints to propose a fair starting point in microtokens.
This is the beginning of a system that can evolve into adaptive, data-informed pricing over time.

Individually, these don’t change what a visitor sees.

Together, they set the stage for a product that learns and improves instead of guessing.

Why it matters

Analytics, refactors, and “internal pricing systems” all sound like back-office work.

But they directly affect how Functory feels:

With GA4, growth is no longer a mystery — you can see which channels and pages actually matter, and focus energy there.
With a cleaner backend, each new feature doesn’t have to fight the ghosts of old decisions.
With automatic pricing, creators move closer to the dream experience: upload function → get a sane price → tweak if needed → ship.

The long-term goal is simple:

“Functory should understand enough about your function to help you price it fairly, not leave you guessing in the dark.”

Today is just the first step.

How we built it

Integrated the GA4 snippet into the frontend and wired it to key navigation and product events.
Chose a minimal initial set of events to avoid noise while still answering the basics: where do people arrive, what do they touch, and where do they drop?
Verified that events flow correctly into GA4 so future dashboards and funnels can be built on top.

On the backend:

Extracted and cleaned up parts of the billing and core logic to make responsibilities clearer.
Paid down some technical debt that would have made automatic pricing brittle if left untouched.
Sketched a dedicated pricing layer that will own the logic for suggested prices and later, smarter adjustments.

For automatic pricing:

Defined the first version of what a “pricing suggestion” should consider (compute tier, microtoken model, platform safety margins).
Started connecting that logic to the publishing flow so creators can see a suggested price instead of an empty field.

What’s next

Refine the GA4 event model and build simple dashboards: where signups come from, how far people go into the product, and where they get stuck.
Evolve the automatic pricing system from “reasonable default” to “data-informed suggestions” as more runs and costs accumulate.
Keep tightening the backend around billing and pricing so Functory can support more tiers, more traffic, and more creators without losing reliability.

Still early, still small — but these kinds of foundations are what make it possible to grow without guessing, and to price compute in a way that feels fair for both users and creators.

←Back to Timeline