I built a thing. As with most things starting 2022, I primarily build products I'm a consumer of myself. This project emerged from my need to manage a large volume of prints, including direct-to-consumer (DTC) non-fungible token (NFT) artwork prints for premium apparel, caps, packaging, clothing and shipping labels, and anything else that required automation for Outpaint.
First things first, figma plugins are essentially sandboxed mini applications. They have a main thread that can spin off an iframe for their visual widgets. While the fundamentals of the web are all you need to ship, I recommend picking the stack you're most comfortable with. In my case, I defaulted to react but there are tons of boilerplates and tooling built around this ecosystem.
Here's a list of tools I landed up using:
create-figma-plugin boilerplate to get your main.ts and ui.ts files already configured. It also comes with a really useful
I built a thing. As with most things starting 2022, I primarily build products I'm a consumer of myself. This project emerged from my need to manage a large volume of prints, including direct-to-consumer (DTC) non-fungible token (NFT) artwork prints for premium apparel, caps, packaging, clothing and shipping labels, and anything else that required automation for Outpaint.
First things first, figma plugins are essentially sandboxed mini applications. They have a main thread that can spin off an iframe for their visual widgets. While the fundamentals of the web are all you need to ship, I recommend picking the stack you're most comfortable with. In my case, I defaulted to react but there are tons of boilerplates and tooling built around this ecosystem.
Here's a list of tools I landed up using:
create-figma-plugin boilerplate to get your main.ts and ui.ts files already configured. It also comes with a really useful
react components
library so your plugins can feel native to the platform.
for all my database and servers. It's very affordable so I'm unclear on the benefits of a serverless setup. Not to mention, railway comes with templates for
is hands down the best experience when it comes to managing dbs and migrations. you don't bend to its will, it bends to your typescript schemas. the copywriting is killer. what more do you want?
is the newcomer in town. Setting it up required the largest effort, as I needed to consider pricing plans, licensing keys, and how to capture the application state simply.
If you plan to write, tons of plugins I would also recommend stacking them as packages in your Turborepo so you can benefit from the the shared scripts, easy of handling library upgrades and not having to parse through 200 repos to make batch updates. In addition, I also landed up dropping the server repos as packages. This doubles as when you start AI driven driven development using editors such as cursor and zed that greatly favor monorepo so it can pull context across the entire folders.
stacking client server packages in turborepo
Pricing* is always a sensitive topic. There is no fixed price. If customers frequently complain about the cost, it may indicate that the value isn't fully realized, they don't understand it, or they might not be the ideal customers. The product may address only a small portion of their pain points or be the only option available. Ultimately, the price reflects what users are willing to pay. I believe plugins should require a one-time payment, allowing users to choose whether to pay rather than facing recurring charges.
This upfront cost enables plugin developers to invest more time in adding features and attracting new users, rather than focusing solely on maximizing value extraction. Since plugins typically serve a specific purpose, they usually perform targeted tasks rather than generic ones, unlike platforms that can evolve their features.
The only caveat is when your plugin relies on an API with variable costs, where charging a small recurring fee for unlimited or high-threshold use. The basic plan still includes API usage but is capped to prevent abuse.The only caveat is when your plugin relies on an API with variable costs, while I charge a small fee for unlimited or high-threshold use. The basic plan still includes API usage but is capped to prevent unsustainable work.
Another important reminder is that plugins are mini applications. Like most software, they operate as a service-based business, which means there are recurring maintenance costs and support you will need to manage. For paid plugins, you will likely have to deal with taxes and refunds. Price your product based on what you can sustain, rather than undercutting other plugin authors and compromising quality. I have found FigStats to be an incredibly useful tool for tracking analytics and studying other authors.
As always if you have any issues, hop into discord or study the open source plugins on common use cases.
All things being equal pricing is largely a function of positioning and I highly recommend April Dunfords work here. Copy writing plays a huge role in not only what you sell but why you sell.
I have used ChatGPT for much of the past year, so I have some credibility. I've built mostly from-scratch applications, using AI primarily for writing functions and manually architecting structure, and function and domain scopes in my codebase. As always, AI driven engineering is changing at a rapid pace so there is no right way. Here are some useful tactics you can use to build faster, safer, and with more control than simply prompt engineering.
The more specialized you become, the more control you can extract, but that gets tricky when you shift to prompt engineering. Cursor and handful of other products do a remarkable job of enabling you to pick the output, but you often loose control as much is generated. There are also instances, mostly related to styling, where the end result requires so many iterations that you give up promptly (pun intended) and revert to your old habits. I've fallen into the trap of starting with AI, and at the point where I need to intervene manually, I forget to prompt until the next feature.
Use Git commits frequently. Use Git commits frequently. When a significant amount of source code is generated with verbosity, it can be overwhelming to validate if the changes work as intended. Instead of reading through the entire codebase, engage with the product to validate if the changes worked as intended.
Make changes atomically or structured in domains.
Use the product to validate test cases and write them as inline comments.
Manually writing tests, which can be time-consuming, consider visually generating tests for certain features.
In the event that future test cases fail, you'll have a valid commit where the feature works. This is a trade-off that may make sense to fulfill at a later point. Tests ensure that features remain valid at every commit.
You can also generate tests at this point but I personally my productivity and momentum drop sharply so its a personal choice. More companies die due to lack of PMF than having to many bugs. There are other ways you can handle those cases which I will discuss in a future post. Personally 0-to-1 products should focus on customers, getting payments and stellar customer support.
Setup a .cursorrules file to store your system prompts.
react components
library so your plugins can feel native to the platform.
for all my database and servers. It's very affordable so I'm unclear on the benefits of a serverless setup. Not to mention, railway comes with templates for
is hands down the best experience when it comes to managing dbs and migrations. you don't bend to its will, it bends to your typescript schemas. the copywriting is killer. what more do you want?
is the newcomer in town. Setting it up required the largest effort, as I needed to consider pricing plans, licensing keys, and how to capture the application state simply.
If you plan to write, tons of plugins I would also recommend stacking them as packages in your Turborepo so you can benefit from the the shared scripts, easy of handling library upgrades and not having to parse through 200 repos to make batch updates. In addition, I also landed up dropping the server repos as packages. This doubles as when you start AI driven driven development using editors such as cursor and zed that greatly favor monorepo so it can pull context across the entire folders.
stacking client server packages in turborepo
Pricing* is always a sensitive topic. There is no fixed price. If customers frequently complain about the cost, it may indicate that the value isn't fully realized, they don't understand it, or they might not be the ideal customers. The product may address only a small portion of their pain points or be the only option available. Ultimately, the price reflects what users are willing to pay. I believe plugins should require a one-time payment, allowing users to choose whether to pay rather than facing recurring charges.
This upfront cost enables plugin developers to invest more time in adding features and attracting new users, rather than focusing solely on maximizing value extraction. Since plugins typically serve a specific purpose, they usually perform targeted tasks rather than generic ones, unlike platforms that can evolve their features.
The only caveat is when your plugin relies on an API with variable costs, where charging a small recurring fee for unlimited or high-threshold use. The basic plan still includes API usage but is capped to prevent abuse.The only caveat is when your plugin relies on an API with variable costs, while I charge a small fee for unlimited or high-threshold use. The basic plan still includes API usage but is capped to prevent unsustainable work.
Another important reminder is that plugins are mini applications. Like most software, they operate as a service-based business, which means there are recurring maintenance costs and support you will need to manage. For paid plugins, you will likely have to deal with taxes and refunds. Price your product based on what you can sustain, rather than undercutting other plugin authors and compromising quality. I have found FigStats to be an incredibly useful tool for tracking analytics and studying other authors.
As always if you have any issues, hop into discord or study the open source plugins on common use cases.
All things being equal pricing is largely a function of positioning and I highly recommend April Dunfords work here. Copy writing plays a huge role in not only what you sell but why you sell.
I have used ChatGPT for much of the past year, so I have some credibility. I've built mostly from-scratch applications, using AI primarily for writing functions and manually architecting structure, and function and domain scopes in my codebase. As always, AI driven engineering is changing at a rapid pace so there is no right way. Here are some useful tactics you can use to build faster, safer, and with more control than simply prompt engineering.
The more specialized you become, the more control you can extract, but that gets tricky when you shift to prompt engineering. Cursor and handful of other products do a remarkable job of enabling you to pick the output, but you often loose control as much is generated. There are also instances, mostly related to styling, where the end result requires so many iterations that you give up promptly (pun intended) and revert to your old habits. I've fallen into the trap of starting with AI, and at the point where I need to intervene manually, I forget to prompt until the next feature.
Use Git commits frequently. Use Git commits frequently. When a significant amount of source code is generated with verbosity, it can be overwhelming to validate if the changes work as intended. Instead of reading through the entire codebase, engage with the product to validate if the changes worked as intended.
Make changes atomically or structured in domains.
Use the product to validate test cases and write them as inline comments.
Manually writing tests, which can be time-consuming, consider visually generating tests for certain features.
In the event that future test cases fail, you'll have a valid commit where the feature works. This is a trade-off that may make sense to fulfill at a later point. Tests ensure that features remain valid at every commit.
You can also generate tests at this point but I personally my productivity and momentum drop sharply so its a personal choice. More companies die due to lack of PMF than having to many bugs. There are other ways you can handle those cases which I will discuss in a future post. Personally 0-to-1 products should focus on customers, getting payments and stellar customer support.
Setup a .cursorrules file to store your system prompts.
