Polishing Dynamic Pricing, Honest Catalog Signals & A Calmer Core

The problem

Dynamic pricing, creator dashboards, and catalog discovery were all ideas inside Functory — but too many of them were still stuck in my head or hidden in the backend.

A few concrete gaps:

• The backend could conceptually handle dynamic pricing, but there was no clean way to submit, store, and validate a pricing script from the product itself.
• The UI still behaved as if pricing was mostly static: function cards and detail pages didn’t explain or reflect how pricing was actually computed.
• The “My Functions” page existed but felt broken:
• Content was technically there but visually invisible because of layout / styling issues.
• Action buttons didn’t reliably take you to the function page, its settings, or any stats view.
• The catalog categories looked like filters, but they weren’t really wired to meaningful semantics.
• “AI”, “Finance”, “Utilities” were more labels than actual logic.
• There was no sense of “what’s hot” — no ranking for the last 24 hours or 7 days.
• And underneath all of this, a giant core file was slowly becoming a liability: too big, too coupled, too intimidating to change.

If Functory wants to be a place where creators trust the platform and users can actually discover good functions, these basics can’t stay fuzzy.

What shipped

1. A safer path for dynamic pricing scripts

• Added a backend endpoint that accepts a function’s dynamic pricing script and related config, then persists it in a controlled way.
• Put guardrails around inputs:
• Strict schema validation on the payload.
• Clear separation between what gets stored as code and what is treated as data.
• Basic sanity checks to prevent obviously dangerous constructs before a script ever runs.
• The goal isn’t to solve all security questions in one day, but to move from “no path” to “structured, reviewable path”.

2. UI that actually shows dynamic pricing

• Updated function cards so they can show:
• Fixed prices when a function uses static pricing.
• A visual hint and label when a function is priced dynamically.
• Updated the function detail page to:
• Explain whether pricing is fixed or dynamic.
• Surface the effective price users will pay, while still being honest that some logic runs behind the scenes.
• Small touches, but together they reduce the gap between “what the platform does” and “what the user understands”.

3. “My Functions” as a real management surface

• Fixed the rendering issue where the list content was present but effectively invisible due to styling/opacity problems.
• Cleaned up the layout so the page feels like an actual cockpit rather than a glitchy prototype.
• Wired the action buttons so they now:
• Link reliably to the function’s public/detail page.
• Link to the existing function settings/edit page.
• Link to a new per-function stats view.
• Added a protected route for per-function stats:
• Only the creator (or an authorized owner) can access it.
• The backend checks both authentication and ownership before returning stats.
• It’s still early, but creators now have a tangible “home” to manage each function.

4. Catalog categories with real meaning and lightweight popularity ranking

• Made catalog categories depend on function tags:
• “AI Models” → functions tagged with #ai.
• “Finance” → functions tagged with #finance.
• “Utilities” → functions tagged with #utilities.
• Implemented a popularity ranking using run metrics over:
• The last 24 hours.
• The last 7 days.
• Defined a simple scoring formula based on recent run counts (and room to refine later).
• To avoid hammering the database:
• Added a place to store aggregated scores instead of recalculating everything on every request.
• Introduced a small background-style update strategy (or at least cached computation), with careful attention to how and when scores are refreshed.
• When schema changes were needed, they were shipped via:
• An idempotent Alembic revision on alembic.dev.ini.
• Validation in dev.
• Then promotion to alembic.prod.ini once it behaved correctly.

5. A calmer, more modular core

• Started breaking down an oversized core file into smaller, focused modules.
• Pulled apart responsibilities so that:
• Pricing, billing, and popularity logic live in their own areas.
• “Core” becomes more of a stable backbone than a dumping ground.
• The refactor is deliberately incremental:
• No big bang rewrite.
• Just making it easier for future changes to be safe, testable, and understandable.

Why it matters

None of today’s changes are flashy on their own, but together they quietly make Functory more honest and more sustainable.

• Creators now have a clear, safer way to attach dynamic pricing logic to their functions.
• Users see pricing that aligns with reality instead of a static label that may or may not reflect what happens on run.
• The “My Functions” page begins to look and feel like a real control panel instead of a broken prototype.
• The catalog gains a first sense of structure (tags) and pulse (recent popularity), which will be essential as more functions arrive.
• The core of the codebase becomes a little less scary, which is important if Functory is going to grow beyond a single person’s head.

Small steps, but each one reduces friction and confusion for future users — and for future me.

How we built it

• Defined a clear backend contract for dynamic pricing scripts and stored them with validation and basic safety checks.
• Reused existing billing primitives so dynamic and fixed pricing share the same microtoken pipeline instead of inventing a separate path.
• Updated the cards and detail pages to show pricing mode and effective price in a way that doesn’t overwhelm non-technical users.
• Debugged and fixed the visual issues on “My Functions”, then methodically wired navigation:
• From list → function page.
• From list → settings/edit page.
• From list → creator-only stats.
• Implemented tag-based category filters in the catalog and added a score computed from recent runs, with aggregation to avoid per-request recalculation.
• Introduced or updated an Alembic revision (dev first, then prod) for any new tables/columns needed for popularity or stats.
• Started splitting the core file along logical seams so that future changes can land in the right place instead of adding to the giant blob.

What’s next

• Tighten validation and sandboxing for dynamic pricing scripts, including clearer error messages when something is rejected.
• Expand the per-function stats page so creators can see not just counts, but trends and revenue in a way that stays simple.
• Iterate on the popularity score (weighing recency, failures, and maybe creator-set signals) once there’s more data.
• Continue the core refactor gradually, aiming for modules that are small enough to be comfortable for contributors who weren’t there on day one.
• Keep polishing “My Functions” so it becomes the default place creators open when they land on Functory.

Still early, still imperfect — but each of these changes makes Functory a bit more honest, a bit more usable, and a bit easier to grow without breaking everything.