Solo Developer Builds Custom Expression Engine to Solve 'Template Explosion' Problem in Image Generation API

When a Pictify customer asked whether they could display a 'PRO' badge on a card only when a user was on a paid plan, founder Suyash Thakur's initial answer was no. At the time, Pictify operated like most image generation APIs: templates accepted variable placeholders, and backend code swapped in values at render time. Simple, but inflexible.

The customer's follow-up question made the limitations starker. They also wanted to change a card's background colour based on a numerical score — green for 80 and above, yellow for 50 to 79, and red for anything below. Without conditional logic in the template itself, that meant maintaining six separate templates: two badge states multiplied by three colour variants. Add further conditions and the count doubles with each new rule.

Thakur heard the same complaint from five other customers within a month. 'Every new condition doubled the template count,' he wrote in a technical post published this week. 'Their simple image API was turning into a combinatorial nightmare managed entirely in application code.'

The core product insight driving the project was straightforward: the people who design and manage templates — marketers, product managers, designers — should not need to file engineering tickets every time they want to add personalisation logic. That logic, Thakur concluded, should live inside the template itself.

Before writing any code, Thakur spent a week evaluating existing tools. His requirements were specific: the system needed to safely evaluate boolean expressions from user-supplied input without executing arbitrary code, and it needed to work at the level of individual canvas objects within a rendered image. No off-the-shelf solution met all the constraints.

The result was a custom-built expression engine of approximately 1,000 lines that Thakur integrated directly into Pictify's rendering pipeline. Templates can now express rules such as conditional visibility, dynamic colour assignment, and variable-driven layout changes. The API caller sends data; the template evaluates conditions and renders accordingly — one template handling what previously required dozens.

The project is notable as an example of a single developer diagnosing a systemic product limitation through customer feedback and building infrastructure-level tooling to resolve it. Thakur, who handles Pictify's backend, frontend, editor, and renderer himself, described the expression engine as transforming the platform 'from a rendering utility into something genuinely useful.'

Why This Matters

For developers and product teams using image generation APIs, the 'template explosion' problem is a real and underappreciated source of engineering overhead — this solution demonstrates a credible architectural alternative.
Embedding logic at the template layer shifts control from engineers to non-technical stakeholders, a pattern with broad implications for how no-code and low-code tools evolve.
As a solo-founder case study, it illustrates how customer feedback loops, when acted on systematically, can drive foundational infrastructure decisions rather than incremental feature additions.

Background

Image generation APIs have existed for years, primarily as rendering utilities: a developer defines a template, passes variables, and receives an image. Platforms like Bannerbear, Placid, and Pictify popularised this model for use cases such as social media cards, certificates, and personalised marketing assets.

The variable substitution model works well for simple personalisation but breaks down when output needs to vary based on conditional logic. Historically, this logic lived entirely in the calling application — developers would select from multiple pre-built templates based on business rules before making an API call. This approach scales poorly as the number of conditions grows.

The broader software industry has long grappled with similar problems in templating systems. Solutions range from full scripting languages embedded in templates (as in server-side rendering frameworks) to constrained expression languages designed for safety in user-controlled environments. Pictify's challenge was finding an approach suited to a visual canvas rather than a document or webpage.

Key Perspectives

Pictify and its founder: Thakur frames the expression engine as a product-level necessity rather than a technical indulgence, driven directly by customer pain. His argument is that logic belongs in the template layer to empower non-engineers. API users and customers: The customers cited in Thakur's account were already solving the problem themselves — by duplicating templates and managing selection logic in their own codebases. Their preference for a platform-side solution is clear, though it also means trusting the API with more business logic. Critics/Skeptics: Embedding expression evaluation in a cloud rendering service introduces security and complexity concerns. User-supplied logic must be carefully sandboxed to prevent code injection or unintended behaviour. The decision to build a custom engine rather than adopt an existing solution also carries long-term maintenance risk for a solo developer.

What to Watch

Whether Pictify publishes technical documentation or open-sources any part of the expression engine, which would allow independent assessment of its security model.
Customer adoption rates for the new conditional templating features — uptake will indicate whether the product insight translates into commercial value.
How larger competitors in the image generation API space respond; if the feature gains traction, template-level logic could become a baseline expectation across the category.

ZOTPAPER