I’ve always wanted to be a writer. Not the writer that publishes a book, but someone who can think through writing.
Reading simpler language made me realize I didn’t have any restrictions holding me back as I was equally familiar with the word choice I was consuming. I didn’t struggle with ideas for writing — I struggled with sentence constructions and rhythms I enjoy when I realized can be resolved using LLMs. LLMs can become a learning tool for my deficiencies.
With the help of LLMs and a few pointers I've been able to write more freely unabated and I hope these are helpful for writers, particularly non-fiction writers, that are starting at ground zero.
Write like you talk. Sure, you’re going to have a lot of punchy notes and fillers words but those can be corrected later.
Stop yourself from rereading. When I write, I often have a tendency to go back and read chunks while I’m waiting for my next thought or point to emerge. Or I’ve made a point, and I don’t know how to proceed to the next one. Maintain writing and rereading as separate activities. It also doubles as a way you save time you could have spent writing more.
Optimize for maximum idea creation. If I’m stuck in the writing process, go back to the core argument of this blog post was trying to refute and pretend you’re speaking to a friend and make those points again. Did you find something you missed out? Try the steel-man argument — what is the unique insight most reasonable people will argue against? What life experience triggered you to write on this topic? Did you observe something in the wild? The point is to create content, not quality content as the editing process allows for those refinements. First bulk, then cut.
I’ve always wanted to be a writer. Not the writer that publishes a book, but someone who can think through writing.
Reading simpler language made me realize I didn’t have any restrictions holding me back as I was equally familiar with the word choice I was consuming. I didn’t struggle with ideas for writing — I struggled with sentence constructions and rhythms I enjoy when I realized can be resolved using LLMs. LLMs can become a learning tool for my deficiencies.
With the help of LLMs and a few pointers I've been able to write more freely unabated and I hope these are helpful for writers, particularly non-fiction writers, that are starting at ground zero.
Write like you talk. Sure, you’re going to have a lot of punchy notes and fillers words but those can be corrected later.
Stop yourself from rereading. When I write, I often have a tendency to go back and read chunks while I’m waiting for my next thought or point to emerge. Or I’ve made a point, and I don’t know how to proceed to the next one. Maintain writing and rereading as separate activities. It also doubles as a way you save time you could have spent writing more.
Optimize for maximum idea creation. If I’m stuck in the writing process, go back to the core argument of this blog post was trying to refute and pretend you’re speaking to a friend and make those points again. Did you find something you missed out? Try the steel-man argument — what is the unique insight most reasonable people will argue against? What life experience triggered you to write on this topic? Did you observe something in the wild? The point is to create content, not quality content as the editing process allows for those refinements. First bulk, then cut.
Separate your writing from your editing process. I didn’t quite think of the ideation phase and the editing phase engaging two different parts of your brain hemisphere. Not only should they be done separately, ideally they’re done in separate physical spaces and times of the day to allow your internals to realize these are separate activities.
If forming structure is difficult, write in bullet points. As an engineer, I often think of building a system as largely critical user experiences and then building out pieces of the system as high level modular functions — and then have LLMs write these detailed functions that are largely syntactical and are something LLMs are fairly good at today. Similarly, once you jot down your bullet points — take each one at a time and expand your thoughts on them, see if you can find connected thoughts between those points where one flow from one to the next. They might not exist and that is okay. In fact assume they won’t exist as you don’t want the added subconscious pressure in the writing phrase.
I’m still learning elements on style but here are some tips I’ve picked up reading some books on writing. Remove all adjectives and see if it clarifies or simplifies your writing. Convert active to passive voice — this hammer to the nail isn’t a simple change — you might have to rewrite and rephrase nearby [statements]. I’m not so sure that’s a perfect word choice so I’ll drop the [placeholders] around phrases or words I feel need revisiting.
Once you’ve dropped all your thoughts and arguments onto a page, LLMs are your swiss army knife. Ask it to help you find better word choices for the [brackets] in this given context. What is redundant? Have it recommend punctuation changes and why it recommends doing so. It’s about learning how to fish as you fish. Learning to write as you write. The best place to learn is in the context of your own work.
Ask LLMs how many arguments have been made and if any are not clear enough require more analogies or background. Ask it to distill what it learnt from your post in a single sentence and verify if it matches your original title. This helps ensure your writing achieves its intended purpose and maintains focus throughout.
If you’ve written enough modular content as modular streams of thoughts, it could potentially aid in help restructure and reshuffle your writing.
If you've written enough modular content, LLMs can serve as structural advisors. They can help restructure and reshuffle your writing, ensuring ideas flow naturally from one to the next.
Beyond basic editing, LLMs can enhance your creative process. They can generate single-line titles, suggest alternative ways to express ideas, or help develop compelling analogies that strengthen your arguments and do mundane work as citing your sources into your footnotes. The goal isn't to replace your voice but to refine and amplify it.
And there you have it. My simple guide to writing.
Attached is a brief snippet of how to engage with LLMs to help you in your editing process.
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. railway.app 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 common templates so I repurposed the drizzle hono package for my usecase. drizzle orm 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? polar 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.
Separate your writing from your editing process. I didn’t quite think of the ideation phase and the editing phase engaging two different parts of your brain hemisphere. Not only should they be done separately, ideally they’re done in separate physical spaces and times of the day to allow your internals to realize these are separate activities.
If forming structure is difficult, write in bullet points. As an engineer, I often think of building a system as largely critical user experiences and then building out pieces of the system as high level modular functions — and then have LLMs write these detailed functions that are largely syntactical and are something LLMs are fairly good at today. Similarly, once you jot down your bullet points — take each one at a time and expand your thoughts on them, see if you can find connected thoughts between those points where one flow from one to the next. They might not exist and that is okay. In fact assume they won’t exist as you don’t want the added subconscious pressure in the writing phrase.
I’m still learning elements on style but here are some tips I’ve picked up reading some books on writing. Remove all adjectives and see if it clarifies or simplifies your writing. Convert active to passive voice — this hammer to the nail isn’t a simple change — you might have to rewrite and rephrase nearby [statements]. I’m not so sure that’s a perfect word choice so I’ll drop the [placeholders] around phrases or words I feel need revisiting.
Once you’ve dropped all your thoughts and arguments onto a page, LLMs are your swiss army knife. Ask it to help you find better word choices for the [brackets] in this given context. What is redundant? Have it recommend punctuation changes and why it recommends doing so. It’s about learning how to fish as you fish. Learning to write as you write. The best place to learn is in the context of your own work.
Ask LLMs how many arguments have been made and if any are not clear enough require more analogies or background. Ask it to distill what it learnt from your post in a single sentence and verify if it matches your original title. This helps ensure your writing achieves its intended purpose and maintains focus throughout.
If you’ve written enough modular content as modular streams of thoughts, it could potentially aid in help restructure and reshuffle your writing.
If you've written enough modular content, LLMs can serve as structural advisors. They can help restructure and reshuffle your writing, ensuring ideas flow naturally from one to the next.
Beyond basic editing, LLMs can enhance your creative process. They can generate single-line titles, suggest alternative ways to express ideas, or help develop compelling analogies that strengthen your arguments and do mundane work as citing your sources into your footnotes. The goal isn't to replace your voice but to refine and amplify it.
And there you have it. My simple guide to writing.
Attached is a brief snippet of how to engage with LLMs to help you in your editing process.
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. railway.app 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 common templates so I repurposed the drizzle hono package for my usecase. drizzle orm 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? polar 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.