whisper flow

purpose: effortless voice dictation in every application
use cases: responding to emails, writing documentation, writing these blog posts, and dictating prompts in my Zed editor and agent models that I’m constantly swapping. Works on iOS as well.

cost: $12/mo with student discounts

dia browser

purpose: lightning fast browser with builtin AI
use case: gathering summaries on writing and videos, deep dive explanations on technical docs and source code. can chat with all your tabs and use this for anything really, but these are my primary uses.

cost: tbd with beta open to arc browser users

raycast

purpose: shortcuts to all your applications via cmd+k. what spotlight should have been
use case: too many to list out here, but would encourage taking a look their hype channel on usecases by your role. will be posting my extensions on https://artivilla.com shortly

cost: mostly free with AI prop tiers or BYOK

val.town

purpose: Zapier for developers, just by writing simply Typescript
use case: creating discord bots, slack bots, X bots, all sorts of bots and simple interface apps. my newsletter aggregator was vibe coded in a matter of days that runs on valtown. view my channel to watch me vibe code a feature.

cost: $10/mo

mymind

purpose: remember everything. organize nothing.
use case: it goes without saying, but it’s impossible to recall all the products, tools, and sites I can instantly bring up. It literally remembers whatever is at the tip of my fingers.

cost: many tiers with $5 lowest

zed editor

purpose: fastest simplest editor on this planet
use case: every professional programmer needs an editor even if you're making simple changes. bring your own keys or use their inbuilt models. or use no AI at all.

cost: free or AI plans w/ token usage

railway

purpose: hosting customer facing applications that can scale infinity
use case: acts like my platform engineer. automated database backups, multi regions, horizontal scaling, logging and traces, monitoring, deployments, PR previews, multiple environments, observability and the rest.

cost: free with paid tiers

supercut

purpose: recordings
use case: screencast recordings for raising an agent

ghostty

purpose: terminal

gitbutler

purpose: virtual branching
use cases: quickly spin up virtual branches and manage multiple pull requests, without getting lost in git branch names or git stashes.

claude code

purpose: leading model for client-side code and multi agents

This isn't meant to be a comprehensive Zed guide - they have excellent docs and an incredible active community where I continue discovering new ways to upgrade my workflow. But the standard way to explore AI is by hitting slash.

In place of the /workflow command, which was their most agentic feature, they've adopted a more robust /prompt command, similar to Cursor's rulesets. Prompts are modular, like isolated functions designed to instruct the LLM to do one thing and one thing only. You can group them and even reference them in other prompts.

For example, if you use the same tech stack for your frontend projects, you can create a prompt to describe libraries used in package.json and their associated coding patterns. You can apply a similar prompt for backend repos and merge them into a single prompt that contains both project repositories.

Here, I'm inserting multiple prompts into my default prompt that is inserted in every chat.

If you prefer LLMs apply the recommended suggestions, the suggest edit prompt can mimic the same functionality until they launch their agentic capabilities.

[todo: link ref to github prompts]

Beyond multiline and multi-file editing, you can run inline assists against all selections, even if they don't match. Want to update Stripe to another third party library? It can try to find the comparable types. I'm sure you can cook up a better use case!

Model context protocol is all the vibes today. Using their universal slash directive, you can create your own extension to interact with a non LLM service, interfaces, or APIs with natural language. More to come on this.

The postgres extension I've tried so far has been surprisingly useful - it checks our db specification against dynamic datasets. For instance, running the postgres-context-server and printing out my tables without instructions allowed AI to compare my defined formatting against how real-life orders are actually stored from user interaction. This provides feedback to improve my schema using real data instead of mocked data.

The consensus is Claude Sonnet 3.5 v2 is great for implementation while GPT-4o is better for planning out drafts.

When tackling a new domain, like building my first set of server APIs or an SDK, I'm less familiar with clean code practices. Asking for best practices or probing alternate ways to perform the same task after the first response is helpful. Often this feels more like a stylistic choice than a matter of correctness. Still, it's a great way to learn.

Claude is very sycophancy. As it stands, it won't replace your mentors since it's very agreeable to your POV. Don't expect it to argue, but do probe it for variations.

Ask LLMs to keep responses succinct with only code snippets or brief explanations if you're familiar with the intended task. When refactoring a function without relying on a library or converting code between languages, you're not trying to learn something new. I'd suggest adding these requests at the end of your prompt.

Keep your explanations brief. Only show me code snippets if asked for code changes while printing out the full function rather than inserting code comment blocks. Do not add user comments.

The following aren't Zed-specific but are powerful for vibe coding or AI-assisted development.

It's good practice to create create feature-focused pull requests so users or API users, if interfacing with a non GUI, remain isolated. This lets you quickly revert commits if needed in production. You can reference these commits via an LLM and ask it to extract features while resolving conflicts with downstream commits.

Like pull requests, writing per-feature tests helps you confidently add new features without introducing bugs or altering existing functionality.

In another world, I might think twice about building custom scripts. At Coinbase, one of our core engineering principles was 1-2-automate. The logic was simple: above a certain threshold, the cost-benefit analysis favors process reuse, which can be as valuable as core code building blocks (aka glue code). This could include operations tasks like reconciling payments, writing test mocks and fixtures, or automating Slack notifications.

Pre-production on Outpaint, I needed to frequently update DB schemas and refine relationships. I wrote an elaborate script across 4-5 prompts to tear down the DB, reconstruct it, and run migrations. Not only is it functional, but it's also clean and beautiful, complete with log files.

Arti Villa on Warpcast

I can read Shakespeare but I can't write like him. I can read much better clean code and tell its organized than I can ever write myself. Check out this script I made in 20 mins to hardreset my dbs. with log prints and everything. https://imagedelivery.net/BXluQx4ige9GuW0Ia56BHw/2918ce2a-2280-4468-8d4d-ad5eec86d700/original https://warpcast.com/ccarella.eth/0x42705d6c

Farcaster

In a way, we've created more work for ourselves but I'd argue it's more fun than repeating tear-downs four times daily - now I can justify the cost.

If you're exploring Zed, consider trying my Ariake theme. Drawing inspiration from traditional Japanese colors and ancient poetry, it offers a serene vibeness through its thoughtfully curated monochromatic palette.

GitHub - artivilla/zed-ariake-theme: Zed IDE Ariake themes inspired by Japanese traditional colors and ancient poetry

Zed IDE Ariake themes inspired by Japanese traditional colors and ancient poetry - artivilla/zed-ariake-theme

https://github.com

Then build the 0 to 1 to serve prosumers and SMBs (small and medium-sized businesses). The long tail of companies requires only a few core features, and your goal is to fulfill those needs. This is typically easier to accomplish with smaller teams.

Moreover, this type of product can be built by engineers who excel at product development, design, and marketing—skills that rarely overlap with traditional computer science graduates. While these technical backgrounds are crucial for scaling technology companies, the immediate challenges are more about skeuomorphic design, where user problems are well-defined but the execution—creating something seamless, easy to use, and delightful—is often the challenging part.

Resend did just that.

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.

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.

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.

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.

"Flaws in communication style are a feature not a bug." — Lex Friedman

"A mistake repeated more than once is a decision." -- Paulo Coelho

"Millions long for immortality who don’t know what to do with themselves on a rainy Sunday afternoon."

"The variation between engineering output is so high that the driven engineers will always be underpaid, and driven towards founding companies."

"Sometimes magic is just someone spending more time on something than anyone else might reasonably expect." -- Raymond Joseph Teller

"Talent is developed in solitude, character in the rush of the world." -- Johann Wolfgang von Goethe

"One can be instructed in society, one is inspired only in solitude." -- Johann Wolfgang von Goethe

"An explained idea and a demonstration of the same idea often have little in common." -- Rick Rubin

"You escape your local maximum by remaining curious."

"We are only as good as the last feature we shipped."

"If you're efficient, you're doing it the wrong way. The right way is the hard way. The show was successful because I micromanaged it — every word, every line, every take, every edit, every casting. That's my way of life." -- Jerry Seinfeld

"Avoid using your past experience as definitive facts or imposition as constraints." -- Rasmus Andersson

"Luck is a function of surface area."

"Learning is the only thing the mind never exhausts, never fears, and never regrets." -- Leonardo da Vinci

"Competence is how good you are when there is something to gain. Character is how good you are when there is nothing to gain. People will reward you for competence. But people will only love you for your character." – Mark Manson

"Success isn't an end state. Success is having the freedom to pursue the continual grind you most enjoy."

"What important truth do very few people agree with you on?"

"Sic Parvis Magna" -- Sir Francis Drake

"Being good in business is the most fascinating kind of art." -- Warhol

"Sometimes you have to play a long time to be able to play like yourself." -- Miles Davis

"We write to taste life twice, in the moment and in retrospect." -- Anaïs Nin

"Your initial deal flow might come from founders, but in order to continue getting deals, co-investors are the best source."

"Bad investors can’t kill your company, but good investors can help you go a long way."

"Creating is a no loss process."

You need experienced but often under appreciated talent; experienced
here doesn’t necessarily mean those who have traditional backgrounds but rather those who have committed to the trail and error of scoping and solving problems that encompass technical roadblocks.

It takes a fair amount of time-exposure to get comfortable with building online. In addition to learning fundamentals of client side, server side paradigms or mobile native workflows, you’re struggling with the unapologetically strict languages, new tools and frameworks that bring an added layer of defaults and opinions and all the auxiliary tools for collaboration including reusable libraries, familiarity with APIs, version control and package managers. This doesn’t even cover best practices that can only be practices or learnt from comparing against failed experiments.

Finding core specialists through open source. With the exception of building a core technology where the innovation is on the lowest levels of the stack i.e first version of blockchains or browser APIs, most applications are solving customer problems and often rely on advancements in core technology and/or major shifts in human behavior. Startups often employ reusable open source technologies to test out initial experiments until they are large enough and decide to improve the existing OSS systems or bring them in house entirely.

Figma built designer tools on advancements in webGL and CRDTs that made their browser-first approach possible. In fact, the early version of the user experience was pioneered by Sketch that targeted interface designers. Searching social coding sites such as Github or Gitlab for webGL enthusiasts and core contributors is a potential avenue.

Finding enthusiasts with experience but are ramping up on learning new stacks and frameworks. Paid meetups, hackathon and dedicated slack and discord channels are often good sources and often have a dedicated #hiring or #jobs channel. Note: The signal to noise ratio in free communities is often very high so I typically discourage spending time where talent typically doesn’t have enough experience to build complete products.

As an specialist frontend engineer here are a list of communities I can recommend:

Nextjs discord
Vercel discussions with a focus on NextJs and frontend technologies.

KCD discord is the channel by Kent C Dodds, a prolific javascript educator and has a broad active community of learners.

FramerX discord and dedicated Webflow experts are tools based communities or services to find experts in low code with a focus on marketing and content heavy sites.

For building type-safe APIs
GraphQL discord
tPRC discord
Prisma

Spline discord for finding artists and web creators building 3d sites

But the caveat here is achieving a successful passive strategy requires picking up the low hanging fruit and then some. The process can be automated but initiating those processes requires upfront work and given there is no right way to get deal flow and the medium continues to evolve, there will always be a need to build some active strategies in to the mix. In order to become “passive” successfully you need to build up the right “channels” that meet your criteria and identify to your thesis and continue to actively help founders or add value to co-investors such that the flywheel continues to meet your goals.

Let’s define what my inbound success criteria is – similar to HustleFund’s hilariously early investments, I lean heavily on investing in pre-seed and seed stage deals aiming to hit 10-20 deals a year with a minimum 1k check size annually. In order to land success early stage, you would need to try at 100+ investments to hit a probabilistic ratio to land 100x bets. Learn more on portfolio construction here. In addition, a significant portion of my investments are QSBS qualified or invested through my AltoIRA alternative asset Roth IRA, accounts to maximize investing with no tax on gains if the sole purpose is to continue investing, via early acquisitions or liquidity. As long as the investing accounts are partitioned off, you can repurpose any proceeds for future investments.

Given the best deals are oversubscribed*, in order to win this strategy, you need to start active-passive and shift passive-active. That’s a mouthful so what do I mean? To start “active-passive” means finding “channels” where you can get deal flow and then find co-investors who are already participating in those deals or “channels”. I’m in well over 21 syndicates on Angellist. A lot has been said about the signal vs noise ratio on joining syndicates on Angellist but given the enormous existing network of investors, if we believe the best investors remove friction on wiring checks quickly, it will continue to attract the best syndicate leads and consequently deal flow.

As you amass enough syndicates with high quality and volume of deals, you can advance from discovery to your selection process. We’ll skip selection for another writeup but it’s critical to have an investment thesis. Investing by nature is opportunistic so it requires having a view of the world where the future state has products and services that will be infinitely more valuable that are under appreciated or simply do not exist.

You can have multiple thesis but in order to be an effective passive-active investor, you believe something of the world AND can provide value given your unique brand & skills. However, here is a cheat code. You can greatly increase your value by making your existing network active.

I recall the excitement when I first reached out to a founder based in Egypt who had a strong product design background and wanted help with his GTM and fundraising process. I felt helpless. It took me years to realize actively helping meant putting in the effort to reach out to my own network and paying attention to a diverse set of operators and investors who can and are willing to help. Through my experiences, here is what I believe to be true of the future state of the world.

Investing in private companies is becoming more mainstream over the next decade and new risk profiles will underwrite a new class of emerging investors. How we raise funds, who we raise from are becoming universal and accessible and the tools and services unlocking the formation of internet-enabled businesses is ripe for disruption. Technological advancements in fundraising and utility in web3, ease of distribution through new media and the creator economy and trends in AI, no code and low cost infrastructure capture a significant mindshare in my investing decisions.

As an active operator and engineer I spend majority of my working week building 0 to 1 net new products that further enable developers to create multi-million dollar ventures. In addition, as an engineer working in venture-backed technology companies for over a decade, I’m continually exposed
to products that form a vast majority of successful SaaS b2b2 technology companies.

There isn’t a single way to source deal flow and there certainly isn’t a single way to add value. Here are few steps I’ve taken to expand deal flow.

• Joined well known angel networks HustleFund, Gaingels with diverse investors and build relationships complementary to your own brand/skills sets.

• Joined Alumni networks dated back from high school, Slack channels from past jobs, web3 DAOs I’ve actively participated in, and any online communities I could think of. If you’re an active web3 developer you can also get access to exclusive communities of builder and hackathon networks.

• Find operators who run Syndicates you’ve worked with or have come to learn that match your investing thesis through podcasts, newsletters, and events.

• Leverage twitter to meet interesting new investors from your initial group.

• Upcoming startup founder networks where operators are looking to build something i.e. OnDeck, Pioneer, raise funds i.e. YC list, RaiseSeed, where builders are building profitable companies ie. Acquire.com, IndieHackers, or launching new products ProductHunt are all ways to complement your deal flow.

• Track new founders under ‘stealth startup’ or ‘starting something new’ by scraping twitter, Harmonic.ai and Crunchbase profiles.

• Follow builders and developers on social code sharing platforms ie. Github, Gitlab and track their recent projects, commits and highly sought after open source libraries that have the potential to become on prem services.

In addition to joining, I would recommend reaching out and lending a hand simply by asking syndicate leads on how you can help them with the skills you currently possess.** Key is to join for quality as quantity will come with time and repetition.

You can pair these inbounds with any distribution channels you create through blogging, podcasts and dinners with operators. Simply letting people know you are investing in your social media profiles will get you access to deal flow.

While founders have a vast network of founders who have already started companies, a huge percent are new founders who do not have existing networks. And professional investors including emerging managers and large scale venture capitalists have built up the largest deal source simply being around for a long time. And often that deal source won’t fit their criteria. I’ve seen a significant portion of new investors that are simply building co-investor relationships and gaining an allocation.

The easiest way to be helpful is to create a collection of angels in your network that can help with jobs you aren’t an expert on and assist with, advise or help vet candidates that can help with a given task.

If we’ve already connected online, feel free to join my network on Brdg

*some links include affiliate links because I share what I use and I use what I believe in. ¯_(ツ)_/¯
*it is preferred to do this in an async manner via a personal website or a 1 pager you can forward

The contrary in itself isn’t true either. I’ve seen plenty of products that have become dominant forces in their verticals that are not loved by their users. Ultimately it all comes down to capital efficiency; how much is a product or service worth and what does it cost to build and distribute it. Macro economics such as the cost of capital largely impacted by interest rates, barriers to entry constructed through regulation all play a major role to what is the underlying unit economics.

All companies that go public when aren’t doing well can be acquired at an attractive rate via private equity. It’s an interesting thought exercise as there is no set valuation and returns are simply the delta between the price equity ratio of the market values and your value of that share at a point in time as well as the entry and exit points during the lifecycle of that company. This is why its’ said, it’s often not enough to be right, others have to be very wrong as when the price is baked into the market price there is no delta.

So what factors demolish your chances of winning even if the company does do well? Luckily there are only two that matter and they’re both in the term sheet; the price you get into the round and the liquid preference stack. If the stacking order is constructed in such as way that future investors can change the rules after the game begins, the house always win.

So what about finding products that bring joy? Those that deliver smooth as butter experiences. Luckily a lot of those are priced in a business KPI such as churn rate, payback period and CAC. Obviously, identifying these metrics when the product hasn’t existed is downright unattainable so picking things early that can’t track these stats but can be derived from the usability is a competitive advantage.

If we’ve already connected online, feel free to join my network on Brdg.

Most often, people use the term startup to define a trade with the hope of building a venture that can potentially grow through raising external capital. And given today's fund structures external capital is seeking a 100x return as there are plenty of options to invest under the lower risk asset returns (i.e real estate, public stock, commodities)

Why does this matter? Because raising funds inevitably reduces your optionality. You're looking to build something that can scale where the product or service can be replicated at no or low marginal cost; and software provides the highest leverage leading to startups being software or software enabled companies.

Given the majority of products lean on software as an enabler, early teams predominantly have a higher breakdown of technical roles. So having a technical role or being closer on a technical spectrum is a favorable skill. Note, people often misconstrue being technical as writing code but its a much larger spectrum.

Here is a breakdown of some hybrid skills that be valuable to any team particularly at the earliest stages.

- Being a product manager with data analysis skills and setting up product events in app or write relational queries to build meaningful KPI dashboards is an easier and valuable skill to master. i.e Segment, Metabase, Zapier, Airtable.

- Designer with the ability to write html/css and often build entire marketing sites or functional framework components that can be handed over to product engineers can help minimize the back and forth and QA process. Webflow, Framer, Storybook, Figma > code conversion tools.

- Marketer with the ability to setup and build instrumentation and processes for your own growth and lead generation experiments. i.e Google Analytics

What has favorably changed in the last decade is the explosion of no code tools and workflow tools that are often built with these roles in mind. It might still require reading the documentation or going through videos on how-to's but the integration process is often interactive and requires at most dropping in code snippets.

Generalists are often favored to specialists or specialists with complementary skills that they do not often possess but are open to trying. Conversely, for technical candidates being able to write, sell, design and be willing to help outside your core role can help you stand out outside the pack.

Given the lower cash salaries and lack of PMF, early teammates are often self-selecting with members that can deal with ambiguous roadmaps but still construct concrete products. Unlike writing and discussions that are often nuanced, writing code is a workflow of binary decisions. You can “checkout” the items in the cart for purchase or you can't. There are a concrete number of flows and screens to complete any task. Regardless of your team's vision, you are building multiple skateboards that will solve a problem for a type of user, and disregard the endless edge cases. Building products with edge cases, through testing is often a luxury and learning to build a muscle that favors how to build for 1 user over a billion gives you more trials that the core need is being met.

On that note, building something for 1 user can often be done as a proof-of-concept so consistently demonstrating the ability to hypothesize, design, build and test this iterative loop is often the most underestimated skill.

Given the explicit nature of product teams to have discussions and think critically which are sought after skills to build robust systems, they often lead early products astray. The term commonly used by software engineers to describe spending excessive time on trivial decisions is "bikeshedding". But early products are subjective at best to define what is trivial.

Instagram added filters well after it was released to the public, but without knowing if the experiment was going to work, spending a week deciding how many filters and what filters to select could have simply been tested in a matter of a day. The contradictory advice I want to present here is that teamwork through experiments is less favorable because that decision making process inevitably takes more time. The benefits of being "exacting" and finding the PERFECT filter is less valuable than trying ANY filter.

While speed is the emphasis given at early stage teams, it's not the entirety of the story. Speed of delivery provides quick feedback loops, reduces "bikeshedding" conversations and reduces edge cases that might not matter simply because the value of learning if this product or service is going to be valuable is greater than all the process that goes with building products and services that work 100% of the time, handle every case or can scale to thousands of users.