How I ended up building for offline, in the age of online

In a world that increasingly moves away from traditional design tools, and more towards AI-based ones, is there really any place for deterministic generation? The bet that I am currently making is yes. There is Let me explain a bit further.

Cost

Machine Learning and LLM usefulness is there. This much is clear, and has been proven. Currently, however, it’s still in the phase where it is looking for applicability and domains. Understanding the fundamental constraints and challenges that LLMs have is important to determine if your organization should or should not integrate them and if so, in what way.

One of the things that companies are betting on is the fact that the cost of a AI subscription is cheaper than that of a human worker. Assuming no rework, and assuming output of a mediocre quality that does the job without reviews and rework. This is going to be the upfront cost.

However! There are secondary costs that are not immediately visible.

1. Reputation cost. If the LLM produces something mediocre that is a hard marketing sell, the brand will bear the reputation cost associated with the fuck-up. This in addition to the next cost.

2. Remediation cost. Often, Polishing the output of a LLM is going to be costing more, because you will need to: A) Understand the problem, which will likely cost the most amount of time (time=money) B) Come up with a plan and a fix.

Most likely, in addition to the above, considering that LLMs are still in the adoption phase, price is subsidized/low to encourage mass adoption. This will 100% change in the future. How do I know this? Well, we only have to look around us for other digital products to understand the basic principle of desirability driving prices.

Privacy

One of the main things that keep popping up and a lot of folks seem to be forgetting is the privacy factor. And this one is a incredibly fascinating topic in of its own.

On one hand, whenever Meta or Google do something that restricts privacy, there is a lot of noise being made about it in society. Rights, data protection etc. Europe is, in that respect, one of the best places to live, being protected by draconic GDPR rights.

But these too seem to be in question lately, with Meta (facebook) lobbying for a set of more lax laws regarding data analytics and permissions. Ok but what does this have to do with LLMs you may ask?

Plenty. Hold your horses!

On one hand, people want to have privacy when talking about said companies, but they seem to be incredibly ok with giving away super personal, or even intimate information about themselves to companies like OpenAI or Anthropic, which are admitting to use that data to “improve models”.

So where does that leave companies?

Well, from a business perspective, there is a clear need to cut down costs on product development, which automatically includes frontend too.

But on the other hand, there is a risk of using LLMs on proprietary code, which will end up in unknown hands to unknown purposes, shifting companies own moats towards AI Companies, while simultaneously getting locked in to a ecosystem that is just beginning to prime them to be bled out financially.

What essentially is going to happen is that LLM providers will dictate how these companies get to do business. And this is where we don’t want to be!

But what about your tool?

When I first built the prototype, I did so for my own use.

Because I always worked in contexts where older, unappealing, unsexy projects, used legacy UI or live code which was no longer covered by any design kit, or any ui sources were still in use. That meant I needed to reverse-design what was live to have a foundation to work with in any future features that would be added. This consumes time and is a really complex process.

First need:

• Import Live HTML into Figma from any type of source code, with reasonable accuracy, to reduce time where I need to create the structure for components.

• Have a capturing mechanism that lives in the browser, does not use any backend service to be snappy, and generate code that is also readable by LLMs. For situations where live code needs to be debugged.

So I spun them up in the form of a browser extension. Easy to do, easy to maintain. But it cost me a huge amount of tokens to polish up. This is where I understood that token cost is going to become a general bottleneck for others too.

So I started thinking about how to address this.

Exporting Code

Since I can capture live HTML, why not export it too ? I was experimenting a lot with AI, and noticed the outputted code was decent, but very opinionated.

This is not something that someone would want to work with in production. Or in prototypes, because it is high fidelity enough to be appealing, risking to become tech debt for any product using it, and it is deceptively polished that consumers or users would think this is live and can be used.

I noticed tailwind being the de facto standard for CSS in most cases, so I decided to optimize for HTML and React with Tailwind as starting points. To do so I studied the Figma nodes API and the CSS flex box model in tandem with the LLM, to have a good understanding of why there are differences and how to tackle them.

Extensive testing took a loooong time to stabilize the generator to a degree that I feel is actually serving 2 purposes quite well:

1. I can use the generated code as-is, to quickly put together a working prototype for any web-ui using Vite as build tool and deploy it to Vercel. This can be used further to get quick stakeholder/user/customer feedback without committing too much to the solution, since it’s driven from Figma.

2. I can build on top of the exported code, clean it up, add properties and data interfaces and have a working, modern, React UI component. This means you’re not working twice for throwaway code, and not spending ANY token to create a prototype with the potential to be discarded.

Everything else I added came naturally to extend the vision of having a hub designed for design-engineers and frontends that helps them work on any frontend heavy project type and cut the time to production in half.

Because I am banking on the fact that a lot of time is spent building the basics of the component and the styling. Most developers use intellisense extensions that convert or suggest in-line-styles and regular css into tailwind production code.

The idea

This is when I put 2 and 2 together.

If I can have a solution that doesn't rely on AI to generate useful code, is private since it can run on any Figma account, even enterprise ones, without sending data back and forth to any server, I have something really really strong in terms of product.

The only problem? Bad timing. Around the same time I started building Grazy is the same time AI-based solutions started to explode.

However, I still strongly believe there is a ongoing use case for my plugin, especially for companies with higher privacy concerns that are not allowed to work with LLMs on proprietary code.

The future

To build on top of the initial product vision, I also plan on adding custom build support that will make the whole plugin much leaner and take less space and use less computer resources to run.

That means adding build flags that control what export modules are shipped for custom builds. Don't want swift or react? Sure. I’ll ship only what you need.

What about other popular frameworks? Well, I am looking into Blazor, React, Vite and Svelte too.

My intention are to take the product out of beta and launch and monetize it, at a much more competitive price point than AI tools, simply because I have near-to-zero costs. So I can afford to be competitive with the price, and undercut similar tools.

Is there a risk that the product fails? Absolutely. And I am ok with that, because I am not making a bet and building for today as much as what happens next.

And my intuition tells me that once prices will start to raise, companies will start to look at alternatives that can still give them plenty of speed without sacrificing privacy, cost, and ecosystem lock in the same way as AI tools do.