Artificial intelligence has dramatically shortened the gap between an original idea and a copycat. Previously, entrepreneurs relied on a natural head start—a window of time to turn a new idea into a business before “me too” rivals could catch up. Formal protections like patents often felt unnecessary or even harmful, since healthy competition fuels markets. I’ve always preferred cooperation with peers over operating in stealth or imposing artificial roadblocks.

Now, with AI able to rapidly replicate products, brands, and features, that head start can vanish in days or even hours. This challenges my belief that a head start alone is enough to incentivize innovation.

Given this shift, it’s worth asking: Are traditional patents the answer? If not, how should entrepreneurs protect and launch new ideas in a world where AI is rewriting the rules?

While a head start can no longer protect new ideas, I’m still not convinced we need legal safeguards in most cases. Speed has a way of making ideas more derivative, and I believe there’s now an opportunity to become more collaborative and less competitive.

Subscribe now

Iteration #11

It’s time to start fixing gameplay balance and UX issues.

Chat Input

Good work computer! Here are a few improvements:

1. Let's try a 20x20 grid. The current grid size feels a little large.

2. When a ship is selected, let's make it orange and blink. Currently, the highlighting animation is a little too subtle.

3. The movement hints shouldn't extend across warp zones. So if a ship is on the top/middle of the quadrant, there shouldn't be a full movement hint at the bottom of the quadrant. This makes it visually confusing where the selected ship is. Maybe instead of a full movement hint across warp zones, a single sector could be highlighted to let players know they can warp and where the ship will come out on the other side.

4. When a ship warps, the direction should remain the same. Currently, if you warp from the top of the quadrant to the bottom, the ship flips direction and faces down. It should remain facing up.

5. Ships that aren't selected should be black. Let's also put the number of the ship on the ship so users can anticipate which ship will be selected next.

V0 Output

Mixed results here. Missed part of the request for the move highlighting, and the visuals for active vs inactive ships could be better. The size of the grid feels better.

Iteration #12

Let’s add an intro screen and continue cleaning things up. I don’t expect the design to get to a good spot with AI alone. I’ll do a mini design sprint to clean things up once we get the functionality in place.

Chat Input

Improvements:

1. It's a little frustrating when the game toggles to a new ship and you inadvertently move in the wrong direction. We might need to change the way switching works. For now, could we introduce the ability to undo the last move?

2. The warp movement hint is confusing. Could we remove that and go with the regular movement hint? It's still important that movement hints don't extend beyond the edges of the map.

3. Let's create an intro screen. The player should be able to choose between easy and hard mode.

4. The easy mode should have starting energy plus energy boosts equal to 130% of the number of sectors. Hard mode should make the total available energy equal to 110% of the number of sectors.

5. Inactive ships should have 75% opacity and the active ship should have 100% opacity.

6. The numbers on ships should be pushed 2 pixels towards the bottom of the ship to be more visually centered.

V0 Output

Playable but the grid is still slightly large for a casual gamer.

Iteration #13

The annoying transition between ships where you accidentally move the newly selected ship has to be fixed.

Chat Input

Looking good. Improvements:

1. It would be nice to undo multiple moves. Can we save a history of 5 moves that can be undone if the player clicks undo multiple times?

2. The transition between ships is jarring. I think there should be a short "power up" sequence between switching ships. The newly activated ship should switch color, then every 50 milliseconds the movement hint should grow from 1 radius to the current radius.

3. While a ship is powering up, movement and actions should be disabled. Once a ship is fully powered up, the player regains access to all actions.

4. Let's remove the ability for players to combine ships. Instead, ships should be treated as obstacles. A player shouldn't be able to move into a sector containing a ship.

5. Resetting the game should take the player back to the intro screen.

6. Let's add a colonization streak. When a player wins by colonizing the quadrant, the streak should be incremented by 1. When they replay, the streak remains until they lose by failing to colonize the quadrant.

V0 Output

So much more usable and the animation for switching ships is pleasant! Also, somehow V0 reverted the logic where moving over a colonized sector causes war and reverts it to uncolonized. I actually think I like this better. Otherwise, the punishment for trying to convert an isolated sector in the middle of colonized sectors is too harsh. This way you waste energy moving over already colonized space, but it’s more reasonable.

I also introduced a colonization streak. It’s currently buggy. I’ll fix it next.

Iteration #14

The grid needs to start smaller for new players and grow as the player clears quadrants.

Chat Input

Improvements:

1. If a player fails to colonize a quadrant, the streak should get reset to 0.

2. Let's try making the grid size variable. When the streak is 0, the grid should start out 10x10. Every time the streak goes up, increase the dimensions by 1. (when the streak gets reset, go back to 10x10)

3. The warping interaction is a little confusing. Let's make it so you can warp in any direction. The D-pad could have a single chevron from a 1 energy, 1 sector movement. Clicking on a double chevron button could be a 2 energy, 4 sector warp in that direction. The hotkey for warping should be shift+arrow.

4. Now that we have a more obvious transition between ships, let's go back to every ship having a different color. Remove the numbers on the ships. The active ship should have 100% opacity, the next ship to be active should have 75% opacity, then 50% opacity, then 25% opacity.

5. Let's remove the energy power-ups.

6. The max energy each ship gets should be the size divided by 2, rounded down. So a 10x10 grid has a size of 10 and each ship get's 5 energy before switching ships.

V0 Output

This was a rough update. V0 made a mistake in a function and couldn’t figure out the victory or losing condition. I tried to clarify and add context 11 times before diving in and fixing the function manually. I’m fine with this. As the complexity of the code base increases, it’s expected that something goes off track.

Iteration #15

I find it annoying that ships automatically switch to a seemingly random other ship. This makes the player feel out of control and kind of ruins the satisfaction of filling the space. Let’s try a version where the player chooses which ship to select next.

Chat Input

Improvements:

1. Instead of automatically switching to the next ship in the sequence, let's try a manual process to select the next ship. When a ship runs out of energy, the player should be able to choose which ship power up next wither by pressing the number corresponding to the ship or clicking on a ship.

2. When it's time for a player to select a ship, show the corresponding number over each available ship.

3. The ship that just ran out of energy should not be selectable as the next ship to power up. It should be greyed out to indicate it isn't selectable.

4. Make all ships black instead of different colors.

5. Slightly reduce the size of each ship.

6. Make the "Reset Game", "Disable Sound", and "Undo" buttons have white text.

7. Instead of "Disable Sound", could we use a sound icon when sound is on and a sound icon with a line through it to indicate sound is off?

8. Instead of "Undo" text, can we use an undo icon to represent that action? Also, the delete key should work as the undo hotkey.

V0 Output

This is somewhat better than randomly selecting a new ship. I think I have a better idea…

Iteration #16

What would the game look like without energy management? Let’s explore that.

Chat Input

Improvements:

1. Remove the notion of energy from the game. A ship's movement should not be restricted by energy.

2. The movement hint should simply be a 2-sector radius around the active ship.

3. Change the number of ships to 3. Instead of each ship being black, make them red, green, and blue.

4. When a ship colonizes space, make the colonization color the same as the ship's color.

5. Introduce a ship selection power up. For each ship, there should be 2 powerups of the same color. They should visually be small circles of the same color in random sectors. If a ship runs into one of these power ups, the ship with the corresponding color should become active.

6. The new loss condition should be a ship running into an obstacle or a previously colonized sector. This is inspired by Star Trek's Prime Directive. Ships are restricted from entering a colonized sector.

7. Ships warping should no longer require energy. A ship can warp in any direction for free. This means a ship as the following movements available. up 1, up 4, right 1, right, 4, down 1, down 4, left 1, left 4.

V0 Output

Wow. This seems to solve a lot of issues and makes actions much more predictable.

Iteration #17

I’m going to reduce the grid size and clean a few things up.

Chat Input

Improvements:

1. The movement hint should be 2 sectors in a straight line and 1 sector in each diagonal direction.

2. Let's scrap the current D-pad and rebuild it. There should be 8 buttons. move up 1 sector, warp up 4 sectors, move right 1 sector, warp right 4 sectors, move down 1 sector, warp down 4 sectors, move left 1 sector, warp left 4 sectors.

3. The power ups should have a 4 pixel semi-transparent outline of the same color.

4. The movement hint should be black with a 15% opacity.

5. Make the grid size of the first level 8x8.

6. Replace "Grid Size: 8x8" with "Level 1 (8x8)".

7. Remove the "Active Ship: 3" label.

8. Remove the "Current Streak: 0" label.

V0 Output

Great iteration! Now, the game is challenging and requires some creative problem-solving. You can intentionally paint yourself into a corner, then warp out of it.

Iteration #18

I’ll introduce a medium difficulty level and change the grid size per level.

Chat Input

Good work robot! The next batch of improvements:

1. Introduce an easy, medium and difficult mode. Easy mode should be a 8x8 grid with red and blue ships. Medium should be 10x10 with red, blue, and green ships. Hard should be 12x12 with red, blue, green, and orange ships.

2. Instead of a victory screen when colonizing a quadrand, show an unobtrusive "Colonized Quadrant" message and increment a "Quadrants Colonized" score. Then immediately randomize and reset the quadrant. The game continues until the game over screen is triggered. Then reset the quadrands colonized score to 0 when the player restarts.

3. The power ups should have a 4 pixel border with the same color but 20% opacity.

4. The movement hints shouldn't wrap beyond the edges of the grid.

5. The size of each sector should be 50% bigger.

V0 Output

Other than the colors and layout, this is a solid foundation for a game.

Iteration #19

It’s time to start cleaning up a few of the design elements.

Chat Input

Improvements:

1. The large gaps between rows in the D-pad should be reduced so the vertical and horizontal gaps are the same. (roughly 8 pixels)

2. At the center of the D-pad, we should add an action inspired by the infinite improbability drive from Hitchhikers Guide to the Galaxy. It can use a question mark as an icon. If clicked, the ship teleports to a random sector. If that sector happens to be an obstacle or a colonized space, it triggers the lose condition. Otherwise, the player gets luck and can continue.

3. When a ship runs into a power up that triggers a ship switch, it should emit a sound effect like an elongated "whoooop".

4. For the red ship, use this color #F7525C.

5. For the blue ship, use this color #5982ED.

6. For the green ship, use this color #16DB93.

7. For the orange ship, use this color #F29E4C.

V0 Output

I really need to figure out how to enable sound effects in my video capture. The movement and ship power-up sounds are solid.

Iteration #20

More design cleanup. Let’s see if we can create an animated end-game sequence.

Chat Input

Improvements:

1. The end game screen should be preceded by the dying ship doing a death spiral, rotating twice while shrinking to a scale of 0%. There should also be a "woo woo woo" sound effect starting at a medium pitch and lowering as the ship shrinks.

2. Instead of a question mark icon for the random warp, it would be better to use a more standard random icon. The text could also be red and pulse to indicate danger.

3. Rename "Quadrants Colonolized" to "Streak".

4. Move the "Colonized Sectors", "Streak", and "Mode" stats to the bottom of the screen. They could be displayed in the footer with small uppercased text with an 80% opacity.

5. The "Reset Game", "Undo", and Sound toggle should be in the top right corner of the screen.

6. The Grabby Alien's text should be in the top left corner.

V0 Output

Nice design iteration. The ship “death spiral” isn’t center mass which actually makes it look somewhat natural.

Conclusion

This game is playable after 20 iterations. Here is the V0 link if you want to give it a test run or fork it.

At this stage, I don’t anticipate fundamentally changing the game. The next 10 iterations will likely be focused on small improvements. Leave a comment if you have any ideas. Thanks for reading!

Subscribe now

We’re going to create a single-player game that I’m currently calling “Grabby Aliens”. It is loosely based on the Grabby Aliens hypothesis that “Loud” alien races should be rapidly expanding their spheres of influence as they eat up space in the universe. Your goal as a grabby alien federation is to colonize a quadrant of space as quickly as possible. I’ll share my chat input and V0’s output for each iteration.

Iteration #1

We’re starting with a blank canvas. V0 prefers creating a React app with Tailwind for styling, which works well for me. So, let’s use the defaults and dive right in.

Chat Input

Let's build a strategic single-player board game you play as an alien federation colonizing a quadrant of space.

Let's start with a 50x50 grid and 3 ships. Each uncolonized grid square is white. When a grid becomes colonized, it turns green.

Setup:

• Each ship starts on a random square.

• All grid squares are uncolonized (white).

• The player starts with 10 "movement".

Gameplay:

• Each turn, the player can select a ship and move it a number of squares equal to the remaining movement. Once they move the ship, their remaining available movement is updated.

• When the player is done moving ships, they can press a "Colonize" button. Every ship will colonize all adjacent squares that weren't previously colonized. Then the movement is reset and the next turn starts.

• When all squares are colonized, the game is over. The player sees an end-game screen that congratulates the player and displays the number of turns it took to colonize the quadrant.

V0 Output

This might not seem crazy. The game is clunky and not yet playable. But V0 understood the input and created a fantastic first iteration. We can work with this.

Iteration #2

There are a lot of potential improvements we can make. I’m not sure how many or how few instructions I should be giving V0 per iteration. I’ll start with 5-10 and see how that works.

Chat Input

Nice! Let's make a few improvements:

1. Let's rename "Movement" to "Energy". This will make the resource more generalizable and usable for other purposes later.

2. Instead of clicking on a ship in the nav, I think ship #1 should be selected by default. The player should be able to tab to cycle through ships. Or pressing the number corresponding to the ship should select it.

3. I think we should disable the ability to click on a grid square to move the ship. Instead, let's have the ship move 1 square at a time using arrow keys. Each movement should consume 1 energy.

4. When a ship moves into an uncolonized square, immediately colonize it.

5. It would be nice to show how far a ship can move when selected. Squares within range could have a semi-transparent black overlay.

6. The white border showing a selected ship is too subtle. Maybe the ship should slowly blink like a cursor.

7. The quadrant is a little too large. Let's try making it 30x30.

8. Hitting Enter should trigger the "Colonize & Next Turn" action.

V0 Output

An overall great iteration. V0 understood every request. The blinking ship request is way too subtle, but I don’t expect a design masterpiece out of V0. We’re really just looking for raw functionality. Once we get close to a playable demo, I’ll start manually editing the CSS to improve the design.

Iteration #3

There are a lot of directions we could go from here. Let’s try adding the ability to buy a ship with your energy.

Chat Input

Nice work! Here are a few improvements:

1. Let's make each square double the width and height of the current squares.

2. Try making the quadrant 40x20.

3. For every 20 colonized squares, increase energy by 1.

4. The map would be more interesting with random spaces that are not colonizable. Let's randomly make 2% of the squares obstacles that ships can't enter and can't be colonized. These squares should be transparent. (instead of white)

5. The player should be able to spend energy to buy additional ships. Let's try making it 15 energy to buy a ship. The new ship should be placed 1 square above the selected ship. If that would place the new ship off the map, try placing it to the right of the selected ship. If that puts the new ship off the map, then fall back to placing the new ship below the selected ship.

6. The "Reset Game" button isn't readable. Let's make the text black.

7. Remove the white border around the game.

V0 Output

Only 3 iterations in and we already have a hint of a playable game. You have to decide if/when to buy an additional ship and you have to be careful not to paint yourself into a corner. It’s a bit of a grind but introducing more things you can do with energy should make the process of “painting the grid” more interesting.

Iteration #4

We should try and make the map more visually interesting and see if we can add more things to do with energy. Maybe upgrading and scrapping ships.

Chat Input

Looking good. Here are a few improvements:

1. Change the grid size to 30x20.

2. Make fewer obstacles that are larger clusters of blank squares.

3. The range hint appears to be broken and only extends 1 square from the ship. It should extend the number of squares the ship could move this turn.

4. Let's increase the energy bonus to 1 additional energy for every 10 colonized squares.

5. The player should be able to scrap a ship for a temporary energy boost. Hitting the spacebar should scrap the currently selected ship. The energy for the current turn should go up by 10.

6. Ships should be upgradable. The cost of upgrading a ship should be 10 multiplied by the current ship level.

7. When ships colonize at the end of each turn, they should colonize a range equal to the ship level.

V0 Output

Now we’re getting somewhere! I like the new logic for the obstacles. It makes the maps feel a little more organic vs the dotted landscape. I’m not sure about the logic for adding a ship though. Ships are so expensive, and they appear next to an existing ship so it’s questionable how valuable they are. Maybe I should reduce the cost.

Iteration #5

Let’s try to make it feel a little more like a game by improving the visuals and adding sound effects.

Chat Input

Improvements:

1. It's hard to see what ship is selected based on movement hints. Maybe it would be better to make the existing movement hint lighter in opacity. To make the selected ship more obvious, there could be an innner movement hint that is darker and a max of 2 squares in range.

2. The map shouldn't scroll horizontally.

3. Let's try making the cost to buy a new ship 8 energy.

4. Let's add 4 energy boosts the player can pick up with ships randomly added to a non-obstacle square at the beginning of the game.

5. Instead of making the ships circles, could we try triangles facing in the direction of the ship's last movement? (up by default)

6. Is it possible to add a sound effect when moving a ship?

V0 Output

Visually, it looks nicer. I didn’t add a gameplay video because the navigation changes size while playing so the map annoyingly jumps up/down based on the size of the nav. I’m tempted to dive in and make some manual design adjustments. But let's continue to focus on functionality at this stage.

Iteration #6

The still feels a little large. It can be a bit of a grind to clear all 486 squares. Maybe a smaller map and the ability to warp from one edge to the opposite edge will help.

Chat Input

Improvements:

1. Let's try a 25x15 grid size.

2. When ships colonize, the radius should be 1 plus the level.

3. Ships should start every turn moving 1 space forward for free.

4. Hitting an arrow key should scroll you up/down the page.

5. Moving a ship onto another ship should cause the ships to merge into 1 ship with the level being the sum of the previous ship levels.

6. It should be able to warp from the edges of the grid to the opposite edge if it isn't an obstacle.

V0 Output

Maybe this is too small of a map. I think an ideal number of moves required to clear the map should be somewhere in the 30 range. This took 9 moves to clear.

Iteration #7

The binary colonized/uncolonized might be more interesting if we try to implement the Kardashev scale and have type I, II, and III civilizations.

Chat Input

Improvements:

1. Let's try a 30x20 grid.

2. The player should start with 2 ships instead of 3.

3. Instead of a binary colonized/uncolonized status. Let's take inspiration from the Kardashev scale and have type 1, 2, and 3 civilizations. The first time a square is colonized, it becomes a type 1 civilization (light green), the second time, it becomes a type 2 civilization (darker green), the third time it becomes a type 3 civilization (darkest green).

4. If a type 3 civilization is colonized, it creates war and the civilization is wiped out making the square uncolonized.

5. Instead of colonizing every square to win, let's have a colonization score. Every type 1 civilization adds 1 point, 2 points for type 2, and 3 points for type 3. To win, you need a score equal to the number of available squares multiplied by 2.

6. The large movement hint path should be slightly darker.

V0 Output

This was a tricky iteration. Maybe I got a little lazy with the prompt because I’ve been getting great results with somewhat ambiguous instructions. In this case, I had to regenerate 3 times and add extra prompts to get the desired result. It would have taken way longer to write this code manually.

Iteration #8

Having 3 types of civilizations is interesting, but it’s visually too noisy. I think we need to bring it back to the binary colonized/uncolonized mechanic. I do like the war mechanic to wipe out colonies that the player attempts to recolonize.

Chat Input

Improvements:

1. Let's go back to the binary colonized/uncolonized gameplay. If a ship enters or colonizes an uncolonized square, it flips to colonized.

2. If an already colonized square is colonized, it triggers a war and flips it back to uncolonized.

3. Instead of squares, let's call them sectors to use sci-fi terminology.

4. instead of a Colonization Score, let's call it "Colonized Sectors". To win you need to colonize all sectors.

5. To start prepping for mobile play, lets add a D-pad to right right of the grid for moving the ship.

6. Let's go back to starting with 3 ships.

V0 Output

The gameplay feels cleaner. Simpler is often better. As I narrow in on a gameplay style, I’ll do less exploration and more refining.

Iteration #9

Buying and upgrading ships seems like an unnecessary distraction at this stage. Let’s simplify and make it so you only control a set number of ships.

Chat Input

Improvements:

1. Let's try removing the notion of turns. Instead, the player should have a finite amount of energy to colonize the quadrant. Without energy boosts, the player should start with roughly 75% of the energy needed to colonize the quadrant. Once all the energy powerups are collected, the player should have around 110% of the energy needed. (extra energy is needed for colonies that get wiped out)

2. If the player runs out of energy before colonizing the quadrant, they should get a game over screen.

3. Without turns, there is no longer a "Colonize & End Turn" action. Please clean that code up and remove the button.

4. Let's remove the ability to buy and upgrade ships. Also please clean up the code.

5. The D-pad buttons should be a little larger with white backgrounds and black text.

V0 Output

This is feeling more puzzle-like. It feels like the right direction for this game. Let’s continue iterating in this direction.

Iteration #10

Switching between ships is clunky. We also need at least 1 additional thing you can do with energy.

Chat Input

Improvements:

1. Disable the ability to toggle between ships. Instead, ships are automatically toggled every 10 energy.

2. Only show 1 movement hint that is between the 2 opacities. Base this off the 10 available movement per ship. If the remaining energy is less than a ships available movement, use the remaining energy for the hint.

3. Remove the ability to scrap a ship for energy.

4. Let's try 4 ships.

5. Add the ability for a ship to warp forward 4 sectors for 2 energy if the sector isn't obstructed. Use "w" as the hotkey. Also, add a button in the center of the D-pad with "w" to warp.

6. If a ship is next to an obstruction and the player tries to move in that direction, leave the ship in place but reorient it in the direction of the obstacle without spending energy. This could be useful for warping over obstacles.

V0 Output

This is starting to feel solid. I occasionally need to clarify instructions, but the accuracy is really good. In this case, V0 was a little confused by the movement hint part. It only took 1 clarification to get it right.

Iterations 11-20 Coming Soon…

I’d share a demo, but it’ll probably take another 10 iterations to get to a good spot. We’re still knee-deep in the weeds at this stage.

Feel free to share ideas. I’ll be happy to give attribution for any concept I incorporate. Thanks for reading!

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.

Subscribe now

Email: Etiquette

Arvid Kahl

When you write cold emails and/or follow-ups, don’t do this.

My inbox is not for you to manipulate. Nobody’s is.

In fact, you even considering this is an extremely disrespectful perspective that I will remember — about you AND the business you represent.

All the Worst,
Arvid

original tweet

Manipulative tactics in cold emails are the worst. I will never connect on LinkedIn with anyone who leads with “I’m still waiting for your response…”. It implies that I was obligated to respond to an initial cold outreach, and now someone is giving off annoyed project manager vibes. No thanks.

I’m not against cold outreach. My time is not so valuable that I’m unwilling to listen to a pitch. All I ask for is basic respect. Abusive language is not acceptable. I also don’t care for flowery compliments from someone I’ve never met.

LinkedIn could be part of the solution instead of perpetuating the problem. By focusing on an ignore/accept workflow, we aren’t giving people who use manipulative tactics feedback to improve their messaging. Here is an alternative workflow:

1. When you are presented with the option to connect with someone, the same ignore/accept interface could be presented.

2. If you click ignore, there should be more options beyond the basic “I don’t know X”. Options could include “Manipulative outreach” and “Pitch not compelling”.

3. Instead of immediately confronting the person with a message like “Dane doesn’t want to connect because your pitch isn’t compelling”, just treat it as an ignore and give macro feedback via analytics. Maybe send a monthly recap “60% of your missed connections were caused by manipulative outreach last month”.

Coding: Live

Michael Aubry

If I built a micro SaaS and live-streamed the process and shipped within 24 hours would you tag along and support?

original tweet

I like the idea of live-streaming the process of building an app. I don’t do it because it’s challenging enough to write code. Talking through my thought process and engaging with a community is beyond my single-tracked ability.

I haven’t really followed the latest Twitch developments. Maybe what I’m about to describe is possible on Twitch or another platform. But here is a system I’d be very interested in as a producer and consumer.

Live-streaming the process of building an app should be more of a team activity and less of a situation where you are looking over the shoulder of a developer. Imagine if 1-2 designers and 1-2 developers are collaborating. When someone takes a break from designing or coding, they become a commentator and engage with the community. They explain what they’ve just accomplished, talk about what other people are working on, get feedback from the audience, and get ready to dive back into their work.

While contributors take turns commentating, viewers can either follow the commentator’s POV or follow any of the contributor screens.

The entire process would allow people to focus on one thing at a time without compromising the viewer experience. I’m sure there are super developers capable of achieving all that while working solo. I find that to be mentally draining. It’ll be interesting to see how Michael approaches live coding.

SaaS: Free Trials

Olly

You're on a SaaS landing page.

What convinces you to start a free trial?

original tweet

I personally avoid free trials whenever possible. As a user, free trials often result in negative experiences:

1. You use a product that solves an immediate need, then forget about it. Several months later, you realize the free trial expired, and you’ve been paying a monthly fee for something you aren’t using.

2. You invest time trying to solve a problem with a free trial but don’t get to the finish line before it expires. Then you’re in an awkward position where you aren’t sure if it solves your problem, but you’re forced to make a huge commitment to continue.

I’m far more likely to sign up for a product with a freemium offering. That gives me as much time as I need to see if the solution works for my use case. Then I can upgrade when I’m ready to ramp up usage.

I even prefer a low-tier paid option over free trials. I’m not after a free lunch as a user. I don’t mind paying to receive value from a product. I just don’t like free trials.

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.

Subscribe now

Valuations: Pre-Seed

Alex Iskold

Raising pre-seed at inflated valuations is terrible.

Day 0 companies should not be valued at $20M. There has been $0 value created.

Founders feel like heroes now, but it takes long time to build & find product market fit and 99% of these will need more capital.

Bad idea!

A pre-seed valuation of $20M is a bad idea. I was tempted to point out edge cases. But if the founders had a big enough previous win to demand such an inflated valuation, they should be bootstrapping.

Overvaluing is setting yourself up for hard times. If your v1 isn’t a home run, and it will likely fall short of lofty expectations, you’ll have a lot of angry people to deal with. Even modest success will feel like a failure. Raising that next round is going to be a problem.

On the other end of the spectrum, founders can’t be bullied into undervaluing their company. Just because you haven’t delivered value doesn’t mean you should be giving away half of everything for a small chunk of cash. If that’s the only option on the table, don’t take it. Find a contracting gig and build on nights and weekends.

Overall, I don’t like pre-seed valuations. There are other options, such as convertible notes, Safe financing documents, and I’ve recently been very intrigued by revenue-based financing. Bootstrapping is an even better option if you can find a way to make it work.

Startup: Skills

Alex Lieberman

I want to be the best at spinning up businesses & finding product-market fit.

Skills I need to crush to get there:
- copywriting
- web design
- human psychology
- audience building
- paid acquisition
- customer discovery
- product development

What's missing?

This is a solid list. If you have some degree of skill in these areas, you can certainly spin up a business. Or you can be exceptional in only a few areas and find co-founders with complementary skills.

One skill I’ve personally lacked that could be added to the list is door-to-door sales. Building an audience and paid acquisition are both great. But in the early days, you must knock on doors and talk to people. In addition to growing your user base and revenue, you learn so much about your product.

Don’t treat customer discovery as a process you do once that gives you marching orders for 5 years. You should always be discovering opportunities to do the most good for the most users.

AI: Note Taking

elvis

ChatGPT is changing how I build things.

- I use it every day
- I mostly use it to generate coding tutorials
- I also use it to fix code
- When it cannot find a direct solution, it can generate hints
- It helps me augment and organize notes

It's really good at all things code.

A lot of ChatGPT use cases aren’t that exciting to me. I still haven’t written a single line of code using an AI tool. But note-taking is a fascinating use case. I’m personally terrible at note-taking. I rely too much on memory. If something is important enough to remember, it’s important enough to prioritize.

The problem with memory is it’s too insular. Just because something from a conversation doesn’t make my personal list of priorities doesn’t mean that it’s not worthwhile. A simple conversation insight could be extremely meaningful to someone else on the team.

If I think about notes more as a collaboration tool, it’s something I’d like to get better at. AI could make note-taking easy. Imagine a Slack integration. At the beginning of every week, ChatGPT could share a condensed list of notes from all discussions happening in all public channels. I’d pay for that.

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.

Subscribe now

Analytics: North Star Metric

Karan Peri

I’m in agreement. It’s tempting to make revenue the north star metric, but it is lagging.

When I led the product team at HackerNoon, our north star was ‘words published’. We also closely tracked ‘minutes of reading time’. By focusing on producing content and using reading time as a quality check, we created a space increasingly desirable for sponsors.

Creating value should be your primary focus. When the amount of value generated is disproportionate to the amount of captured value, invest some effort equalizing.

In our case, we experimented with pricing and various types of ads. The sophistication of our ads increased, and we captured more of the value we created.

If we had started focusing on maximizing revenue, we would have captured a higher percentage of a much less valuable pie.

Javascript: Array Methods

Alamin

I always mix up unshift() and shift(). I just don’t find the method names intuitive. It seems to me that “shifting” should be “making space” for a new item to be added, not removing an item and the remaining items filling the void.

But what are you going to do? Creating a library to rename methods adds to the confusion. Until something better comes along, shifting removes the first element. Seeing this animated guide helps.

One thing to note about these methods is the return values. Whenever you remove an element, the return value is the element removed. Whenever you add elements, the return value is the new length of the array.

CSS: Anchor Positioning

jhey

I love that CSS is evolving to find ways to make javascript hacks obsolete. This is a particularly thorny JS hack. You have to account for several factors, including the position of the tooltip relative to the viewport. Small things like the triggering element being near the right edge vs the top/right edge can trip you up.

The CSS might not look pretty, but it’s much cleaner than JS solutions.

CSS: Tailwind

James Mishra

I’ve held off using Tailwind for various reasons. The biggest was the assumption that it is Bootstrap v2. I hate that Bootstrap tends to make apps look and feel the same. A lot of Tailwind apps also share a similar look and feel. But that is not due to the framework. Tailwind is extremely flexible. The common vibe is due to people not doing the work to customize their implementation.

James’ comment about elitists hating on the framework is fair. The anti-semantic nature of Tailwind tends to turn off a lot of developers. While I certainly don’t count myself in the elitist bucket, the ugly code was probably my #2 deterrent.

Over the last few weeks, I’ve dipped my toes in the Tailwind pool. I’m liking how fast it is to rapidly put together a good-looking interface with a minimal amount of effort required to do things like write CSS and think about properly naming things.

Users don’t care how ugly your code is. They’re happy as long as your ugly code outputs something useful.

I do believe Tailwind introduces some interesting tech debt questions. A rapid implementation of Tailwind is great for launching a v1. It’s not necessarily great for building a maintainable codebase that is easy to improve. A component library and a design system can help. I’ll talk about that more in the future.

Product: Launch

Melanie Balke

I like this approach to scheduling communication leading up to a product launch. Updating too frequently before the 2 week mark risks your pings turning into noise. The 2 weeks, 1 week, and 1 day message strategy feels right to me.

I’ll test this out on my next launch. 🚀

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.

Subscribe now

NPS: Alternative

Jared Spool

People are generally pro-NPS (net promoter score), so this opinion is unpopular, but I don’t like it. It’s a low-effort survey that produces a weak signal for determining how well your product is performing.

Managers might be motivated to implement NPS because good results can justify a raise. If the results aren’t great, they could be used as an accountability tool to punish the product team and get people to work harder.

To be fair, feeding a manager’s ego isn’t the only way to use an NPS score. It is possible to follow up with detractors and do things to activate promoters. But I can almost guarantee this doesn’t happen in practice. I’ve clicked 0 on many NPS surveys over the years, and I’ve not had a single follow-up.

Why are we wasting time doing the easy thing that doesn’t tell us anything meaningful about our products? With a little more effort, we can ask much more meaningful questions.

Directionally, I like what Eastern Bank is doing by asking more specific questions. People often avoid giving negative feedback because they worry about potentially causing someone to lose their job. So I’d opt for more positive wording. Here is an example:

Thanks for using our app! How can we improve? (check all that apply)

• Faster load times

• More intuitive instructions

• More responsive customer service

• Improved design or layout

• New functionality (we’ll follow-up over SMS)

• None of the above, great job 🙌

A survey like this would still be low-friction, but I’d be much happier to see it as a user. It would make me feel like my input is valued and I’m not just a number from 0-10. Product teams would also get a lot more value from the results.

SVG: Morphing Paths

algorithmic

Animating paths in SVG isn’t too difficult, but there are caveats.

1. A basic CSS animation with paths really only works when you transition between 2 paths. If you need to combine more than 2 paths, you’ll likely need a JS solution that involves iterating over points and doing the math to determine new x/y coordinates. I assume that’s what this library does.

2. I’ve found it difficult to work with paths that don’t have the same number of points. The transition is usually pretty janky.

The demo looks smooth. I’ll have to think about use cases to test it out.

Product Philosophy: Reversibility

Martin Fowler & Kent Beck

I’m not an extreme programming expert. I’ve probably spent 1 week of time in an XP environment over the last 20 years. But I find Kent’s article to be intriguing because it hits on 2 key concepts that teams should pay more attention to:

1. Reversibility – It’s shocking to me how teams act as if every decision is permanent. If a decision actually is irreversible, take more time making sure you get it right. But the vast majority of decisions are reversible. For those decisions, you don’t need 100% confidence before taking the leap. Just do it, learn, and revert if needed.

2. Dependencies – Kent really seems to embrace the idea that dependencies are just a fact of life when writing software. If your team is trying to move fast, you don’t always have the luxury of waiting for a design to finalize before you start building. He offers a lot of tips on working around that constraint such as merging teams to maximize communication or automating processes so people are less likely to become bottlenecks.
   
   I think it’s possible to remove a lot of dependencies without going full-on waterfall for project management. I should probably write a whole blog post about this but fundamentally developers should try to work in small iteration cycles and avoid projects with outstanding dependencies.
   
   For example, if a design is in progress and you are starting a new development cycle, avoid work related to the design. Go work on a project that doesn’t have dependencies. Bug fixing is always an option. If the design is ready when you start your next development cycle, pick it up and run with it.
   
   An autonomous workflow is required to minimize dependencies. A manager friendly environment with tight deadlines, no “slack”, and a focus on utilization will be dependency heavy.

Deployments: Bugs!

Damon Chen

There is no obvious answer for determining when a deployment should be held up by bugs or code cleanup. Sometimes you should delay and “do it right”. Other times it’s better to deploy. I agree with Damon. The more experienced I get, the more likely I am to ship a bug.

Here is a question you can ask yourself when you find a last minute bug “Am I delaying the deploy purely because of my ego?”. If you are trying to avoid the embarrassment of someone seeing something that isn’t perfect, then you should get over it and ship the bug. Only hold things up if there is a good reason not related to your ego. An example might be a broken form that prevents users from accomplishing a key task.

Generative Art: Additive Prompting

Nick St. Pierre

If you find it frustrating trying to achieve a certain effect with generative art and Midjourney in particular, check out this thread. Nick goes into exhaustive depth covering a lot of common use cases.

His examples are primarily high resolution photos. But many of the techniques could be used for generating illustrations, sketches, and other styles.

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.

Subscribe now

Product Philosophy: Build First

Brian

This is my mood today. Stop worrying about all the bullshit you think you need to have in place in order to build. Just build.

You don’t need the perfect idea or someone to validate that it’s even a good idea. You don’t need a ‘win’. You don’t need the ‘right’ tools or all the necessary skills neatly lined up. You don’t need a framework, a mentor, a support group, a sabbatical, or a degree.

There are very few legitimate reasons preventing most people from getting started. Once you get the ball rolling, you’re halfway there. Then think like a captain of a ship. Think about where you are headed and the micro-adjustments needed to get there.

I agree with Brian, learn to love the journey. Getting to a nice destination is great, but you’ve got to love the grind.

Scaling: Specialists vs Generalists

Andrew Gazdecki

Hiring generalists as you create a startup and specialists as you scale is generally good advice. I agree with it in principle, but it is more nuanced.

What do generalists and specialists bring to the table?

• Generalists discover opportunities – Generalists are able to combine knowledge from different domains in order to find new solutions. In other words, generalists are “innovators”.

• Specialists capture value – Once you’ve got a solution validated by the market, specialists are better at refining it. As the solution improves, you capture more and more value from the market.

The problem with hiring generalists early and specialists to scale is you lose the ability to innovate. As the market evolves, competitors drive prices down, and needs shift. The well dries up.

It’s more sustainable to think about how you can maintain a team of generalists to continually discover opportunities. As solutions get validated, hire specialists to help scale. At every stage, you need a mixture of generalists and specialists. The composition should change based on product lifecycles.

As products reach the end of their lifecycles, they should go into “maintenance mode”. Reduce how much you invest in new development. Focus on performance, security, and stability.

Instead of laying off all the specialists who scaled the product up, shift people to new, freshly validated opportunities.

Team: Cross-functional Roles

Julie Zhuo

After my previous discussion about specialists vs generalists, I’d like to point out that nobody is purely a generalist or specialist. Even the most well-balanced generalist has specializations. And the most narrow specialist is not a one-trick pony.

This is a great thread by Julie that talks about the value of cross-functional roles in larger companies. Even with a high degree of specialization, I firmly believe that siloing people is bad. You don’t necessarily need people who are highly skilled at everything, that isn’t a reasonable expectation. But you do need highly skilled people who are focused on different problems to work together.

Oil Painting: Tips

Safeyah

Enough about building teams and just getting started. Here are a few oil painting tips by Safeyah. Watching artists manipulate color, light, and texture never gets old.

I’d love to see a redesigned coffee shop that functions like a colosseum where the gladiators are artists. Every morning people start their day by gathering in an open space to watch skilled people perform their craft.

It would be great for artists to get exposure in a community without the pressure to teach. Not everyone is a teacher. It would also energize and inspire the community.

Debugging: Flowchart

Harold Sinnott

I haven’t written Python in a while, but every programming language should have a debugging flowchart. I don’t know how often I’ve run into an error that makes no sense. I find myself pasting gibberish into a google search, desperately looking for a human explanation. This at least gives you enough context to narrow down most issues.

Looking at the error types, I have to say Python is reasonably intuitive. I don’t think I’d have a WTF reaction to any of error types in the chart. There are other Python error types I find less intuitive, such as a GeneratorExit.

Ultimately, programming languages should invest more in the developer experience. The vast majority of errors should be immediately obvious and recoverable within minutes of seeing an error message. A lot of progress has been made over the years. But we’re not there yet.

Subscribe to The Daily Subset and gain the skills needed to become a multiclass developer.

Subscribe now

Creator: Culture

Zack Honarvar

I love what Patreon is doing to empower creators. It has never been easier to become a solopreneur, thanks to tools like Patreon.

One major hurdle I see with today’s creator economy is the high level of risk required to get started. Most people either need to have enough cash saved up to take the leap or work nights and weekends until they hit a critical milestone.

Both options tend to be a stressful deterrent. It kills me to imagine how many creators are stuck in soulless corporate jobs right now.

Why not build a company or a collective composed of creators? In order to join, you need to be some form of community builder. It can take the form of a newsletter, blog, podcast, tutorial series, open-source project, etc.

Everyone on the team would essentially be working half-time on a collective project and the rest of their time building their personal community.

Here are some of the advantages:

1. No managers – Solopreneurs can be fantastic autonomous contributors with an instinct for finding opportunities to add value.

2. No marketing – Members would be encouraged to include the collective in their bios. Then every personal project is basically a growth hack for the collective. Members would also benefit from the collective cross-promoting their projects.

3. Less risk – The stable income extends the personal runway for each member. When they hit a milestone, they graduate and go full-time on their own project.

4. More time – It’s damn hard to make progress on a project if you only have nights and weekends free. Working full-time while also bootstrapping is not sustainable.

Why aren’t more tech startups structured as collectives?

Marketing: SEO

Keval Shah

My personal SEO strategy is simple. I don’t really care about competing for popular keywords. At least not initially. So I don’t do keyword research, link building, or follow all the micro-optimization recommendations.

Instead, I’m going with a long-tail strategy focused on uncommon keyword combinations. By writing a long-form daily newsletter covering 5 different topics, I’ll naturally create long-tail opportunities.

For example, consider this issue and the combinations that might arise from the first 2 sections. In the first section, I talked about a “startup collective”. In this section, I’m talking about “SEO”. I’ll likely rank for terms like “SEO startup collective”. With 5 sections, there are a lot of permutations. (ways to mix and match keywords)

I like that this strategy requires minimal effort and allows me to write more naturally. We’ll see how it works once I’ve produced content for 6+ months.

Web: Components

Lea Verou

I’ve been thinking about components lately. Here is an interesting take on why web components are modular in theory but challenging to reuse in practice. The problem stems from not having more control over how components interact with a surrounding page’s CSS.

Components can be implemented with either the Light DOM or the Shadow DOM.

• Light DOM – Works as if the component were embedded directly into the DOM. Global styles can easily override component styles. This can be problematic. The same component added to different web pages is likely to differ visually.

• Shadow DOM – Components built with the Shadow DOM have scoped styles that do not inherit from global styles. This makes Shadow DOM components more visually stable but harder to configure.

Lea has created a proposal that allows Shadow DOM component authors to declare parts of the component to be stylable from global CSS. This seems like you’d get a lot of the isolation benefits from the Shadow DOM without completely shutting the door. Let’s say your component is a form, and most styles need to be locked down, but you want the input and button elements to look like the other inputs and buttons on the page. It sounds like a nice compromise if the details can be worked out and the implementation is intuitive.

Alternatively, you could use CSS variables. This might not be a perfect solution because it’s more rigid than Lea’s proposal. You also run the risk of a component using variable names already in use which would be problematic. The advantage is variables are reasonably intuitive. Here is a codepen example. I’d likely go with this approach if I were to build a web component today.

HTML: Telephone/SMS

Shripal Soni

I wasn’t aware you could show a phone number that triggers an SMS with a default message. If I were to implement this on a page, I’d consider doing 2 thing:

1. Show a phone icon if using a “tel:” link and a conversation bubble when adding an “sms:” link. This way, people don’t assume clicking the number will trigger a call.

2. I might use media queries to hide sms links for desktop. This depends on compatibility with desktop messaging apps. If compatible, I’d leave it as is. If not compatible, i’d hide sms links.

Writing: Tips

Jonny Geller

My writing is better when I say it aloud. Saying what I type makes it easier to avoid confusing combinations of words.

I should think more about writing for a specific person vs writing for a nameless, faceless audience. “Scaring you to death” might be slightly extreme, but it is directionally correct. It’s easier to connect when your words have a person in mind.

I’m less excited about the warning of becoming too emotionally attached to a scene. There is absolutely a risk of bias. But that emotional connection can also add character. So it’s a little bit of a give-and-take thing. Awareness is good, but don’t avoid it entirely.

Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.

Subscribe now

Product: Time Machine

Nikita Bier

This is an interesting thought experiment to start the day. It’s tempting to look at cases where hindsight is 20/20. What products were on the cusp of greatness only to be realized by key discoveries in future competitive iterations? There are plenty of examples during the dot-com bubble. Ebay comes to mind. That product certainly could have benefitted from future Amazon and Shopify improvements.

It’s also very tempting to go with a more altruistic approach. Could we have a better internet today if the people who created foundational technologies such as Javascript had a clearer idea of how it would eventually be used? Absolutely.

A better internet would be nice, but that might be small potatoes compared to improvements over a longer period of time. What about environment-centric opportunities? What if someone were to introduce modern lithium-ion batteries to the first electric cars built in the late 1800s? Maybe it’s possible electric vehicles could have outcompeted the combustion engine. If so, how would that change CO2 emissions over 150 years? It wouldn’t have solved the problem. But we’d likely be better off.

Ultimately, I’d probably choose an opportunity that balances altruism with a financial upside. I’m not a math wizard, so pulling this off would be damn hard. I’m assuming in this alternate reality that I’d be allowed to restructure my education as needed. I would have introduced the proof-of-stake consensus protocol to Bitcoin. It would have been far more environmentally friendly. And it would have changed the entire trajectory of crypto.

Typescript: Tutorial

Joe Previte

Speaking of a better version of Javascript 👆, here is a tutorial by Joe Previte on Typescript.

I’ve long been in the camp of knowing Typescript is theoretically better than Javascript. But because I prefer to work in very small teams (often solo) and 100% reliability isn’t an absolute necessity, I prefer Javascript. I find it easier to deal with an occasional random type quirk than to continually write verbose code to disambiguate and make type a non-issue.

I know my take is frustrating to Typescript enthusiasts. It’s probably a variation of an excuse they hear all the time. But imagine if the English language required strict type declarations for parts of speech.

This sentence:
I want a glass of water.

Turns into this abomination:
I:pronoun want:verb a:determiner glass:noun of:preposition water:noun.

I suppose the second sentence is less ambiguous, even though the first sentence was entirely straightforward. Still, I’m not anti-Typescript. Reducing ambiguity is a good thing when it comes to running programming languages. I just wish we could achieve that more concisely. I look forward to whatever JS and TS evolve into.

API: REST Tips

Rapid

Nice list of API tips! I’ve certainly been tempted to use verbs in API endpoints instead of nouns. As a refresher, the type of request you make should determine what you are doing with the resource.

GET - Retrieves a resource.
PUT - Updates a resource.
POST - Creates a resource.
DELETE - Removes a resource.

Steve Jobs: A Good Life

James Leighton

I hate that Steve Jobs was too much of an authoritarian. That toxic inspiration has plagued startups for years. But you can’t deny that Steve put out some brilliant quotes. This is a prime example. The fact that the world around us was built by regular people should be a daily source of inspiration.

There is no reason to be held back by imposter syndrome or any other artificial constraint. Your peers are better than you in some areas and worse in others. We all belong. We all have something to contribute.

Procreate: Shadows and Highlights

BeeJayDeL

Adding shadows and highlights is so satisfying. The small tip I love in this video is that you don’t need to add pure black or white for shadows and highlights. Adding a dark purple and then dropping the opacity to blend can bring shadows to life.

A designer should put out flat layered designs for people to practice highlighting. Then everyone can share their work and learn from techniques used by other designers.

Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.

Subscribe now

Product: Development Agency

Cory House

I believe the idea has potential. Here are a few challenges I see and potential solutions:

1) Developer buy-in – Many developers have become accustomed to fighting for high-resolution specs. This is often the result of people being held accountable for unforeseen challenges that arise after a project is poorly planned.

Manager: How long will it take to build X?

Developer: I don’t know. Maybe a week or two…

Manager: Great. Let’s get started. I expect it to be done in a week.

A week later, the developer is scrambling to get the project to the finish line. So many layers of complexity make it obvious that it should have been a 4-week project. None of those considerations were discussed ahead of time. So now the developer has to work twice as hard to produce shitty results that nobody is happy with.

The next project has a developer thinking “I don’t want to do that again. I’ll be much more conservative in my estimate, and I’ll make sure we properly spec it out”.

The above scenario is not healthy. We should not incentivize people to sandbag and guard their time. We should incentivize people to take risks and explore opportunities to deliver as much value as possible. Because of that, I like the “no docs” approach. A great developer unencumbered by a heavy process has the potential to produce significantly more in a fraction of the time.

To make this work, we need to undo some negative programming. Take away the stick and focus on the carrot. Developer comp should be proportionate to the value they create. Treat developers as fractional entrepreneurs.

2) The system should be less reactive – I know many people want to make customers the project managers. It’s tempting to just do what customers ask for in real time, especially as an agency. But being reactive has pros and cons. It’s nice to deliver value quickly, but with no prioritization, it’s hard for developers to maximize their time investment.

Instead of taking a real-time approach, I’d add a 1-day buffer. There should be a system of feedback collection that does not interrupt anything in progress. Just allow all the feedback to pipe up for the day. The next morning, the team should get together and evaluate yesterday’s feedback and plan their day. Once everyone has decided their focus for the day, there should be as few interruptions as possible.

Communication: Async

Nick Bryant

I’ve always been a fan of async communication. It’s opt-in. You can find ways to fit it into your workflow without blocking large chunks of your day. You aren’t obligated to participate in conversations if you don’t add value. There are so many benefits.

In spite of all the advantages, we can’t seem to give up our synchronous communication addiction. I wouldn’t be surprised if the average tech worker spends at least 3 hours in meetings every day.

Maybe the problem stems from our need to verbally communicate face-to-face. We have the tools to communicate face-to-face async. You can record and post short video clips in Slack. But that functionality doesn’t seem to get a lot of usage, at least in my experience.

I don’t know the answer, but I hope we find more meaningful ways to get more out of our sync and async chats. Good luck to Nick on his quest. 🍻

Productivity: Focus on your Strengths

Dini Mehta

It’s a good idea to focus on your core strengths. Strengthening your weaknesses makes you a better generalist, but it’s also a losing battle. You can’t possibly be good at everything. So spend most of your time doing what you are good at and be thoughtful about expanding your skillset.

The outsourcing your weaknesses part is a whole discussion in itself. I believe it is better to collaborate than to delegate. While most people believe in delegating, there is a major flaw in that thinking. How can you effectively delegate if you aren’t a subject matter expert? If it is your weakness, then you are less equipped to make decisions than the expert doing the execution.

In a collaborative environment, experts are able to contribute their strengths while trusting other experts to contribute in areas where they are weak. Creating a collaborative environment is not easy. In a lot of ways, it’s easier to just delegate. But the upside is higher.

Collaboration: Ownership

Hakan Deryal

This is a continuation of the discussion on productivity. 👆

Teaming up with people who are strong in areas you are weak is generally a good idea. One potential red flag here is the use of the word “ownership”. I don’t believe hard boundaries over domains involving absolute authority is a healthy setup. In other words, you shouldn’t say, “I decide everything tech related, and you decide everything marketing related”.

It’s better to say, “I’ll take the lead on tech, and you take the lead on marketing”. The difference might sound insignificant, but it’s meaningful. It means that you, as a technologist, aren’t excluded from marketing decisions. And marketers aren’t excluded from tech decisions. Input from both sides should not only be invited but encouraged. It builds trust and helps the team arrive at better overall solutions.

Domain: Motivation

Alfred Nerstu

Congrats on the name and good luck Alfred! 🎉

It’s hard to put a price on a domain. But one major reason to pony up the cash for a name is motivation. Paying $10k for a name that you feel personally connected to might inspire you to work 10-20% harder than a name you are less excited about. Extrapolate that effort over a year, and suddenly $10k seems like a hell of an investment.

Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.

Subscribe now

Product: Hiring Traits

Carlos Iborra

I like this list of traits. I do worry about hiring someone based on my perception of their health. That seems potentially discriminatory. But it is an otherwise solid foundation.

Here are a few additions I’d consider:

1. Autonomous – While being proactive is often related to autonomy, I think they are different and both valuable. Proactive contributors might rally the troops around a new opportunity. Autonomous contributors might take it upon themselves to explore the viability of a new opportunity.

2. Diversity – Having a team composed of people who lack shared experiences means that you have a much broader set of overall experiences to draw inspiration from.

3. Optimists – This is a trait I’ve been thinking about lately. When you encounter a new opportunity, you need a team capable of mentally exploring the space. Optimists tend to think “There is a path to get from A to B, let’s find it”. Pessimists approach ideas as “This won’t work because of X, Y, or Z”. I’ll take pragmatic optimism over pessimism any day.

Frontend: Framework

Brian Ball

I wouldn’t say I’m a fan of React. There are just a lot of small annoying quirks, like attribute renaming (i.e. className), state management, and JSX. I find it far more intuitive to use Vue, which does a much better job of extending pure HTML.

But I tend to use the React-based NextJS framework because it makes up for some of the quirks. One of the things I love about NextJS is the intuitive routing. You don’t have to manage any routing files. Just add files to the ‘pages’ folder and be aware of a few naming conventions, and that’s it. The same system works for building out an API.

NextJS is also compatible with my preferred hosting platform, Vercel. The developer experience in Vercel is superb. It takes care of all the basic devops requirements you need to get started. Just push your code to a github repo, and deployments are automatic. You can even push to a feature branch, and that’ll trigger a preview deployment!

The only thing I’d like to see improved in Vercel is a more intuitive way to manage assets. Adding image assets to a repo isn’t always ideal, and there isn’t an obvious alternative solution.

CSS: Animated Transforms

jhey

Codepen is a great tool for learning a variety of frontend skills. In this example, you’ve got a complex loading animation with 3d transforms to scale and rotate a cube.

When I see the code shared by jhey, my first thought is to wonder about the 3rd parameter in the scale animations. I’m much more familiar with scaling everything uniformly with 1 param or scaling the x/y with 2 params…so I’d assume the 3rd param scales the z-axis. But I’m not really sure how that works in practice because you can’t really make a div “thicker”.

With Codepen, it’s easy to fork someone’s code. Then strip it down to the bare bones. Remove everything you aren’t concerned with. Remove the shadows and the jumping animation. Make the cube just sit in place so you can manually manipulate an attribute to get a better sense of its purpose.

Once you understand the foundation of how to achieve a desired outcome by adjusting attributes, you’ll be ready to add complexity. Maybe you don’t build back the same animation. Use other skills you’ve previously acquired to derive an entirely new animation.

Learning: Acquiring New Skills

Trey Nobles

I appreciate music from afar. I enjoy how I can use it to positively impact my mood. I like the poetic nature of the lyrics. Music is simply an enjoyable part of life.

I was recently gifted an AKAI Professional MPK Mini MK3, and every acronym in the name is a mystery to me. In fact, I don’t have enough technical music vocabulary to even begin to describe what I’d do with it. It’s just a device with a bunch of buttons and knobs sitting on my coffee table.

The only thing I really have going for me is that I love pushing buttons and adjusting knobs. It’s probably the perfect musical instrument for me. As soon as I find the right cables, I’m excited to make some terrible music. Then maybe I’ll advance from terrible to bad music. If I stick with it long enough, who knows? Someone once said I look like Post Malone. It’s half delusional to imagine making music professionally. I am an optimist, so I know there is some potential path from A to B. But it’s probably not the path for me.

The point is, learning something new requires you to embrace being terrible. If you don’t accept that reality, you give up before you ever get started.

Founder: Zero to One

Shaurya Nagpal

Founding a company and going from zero to one is similar to learning to create music. It’s a different type of skill, but some of the underlying principles are the same. You have to go through a period of time when you have no idea what the hell is going on. It might be scary and feel unnatural. If you do it enough times, you’ll start to feel comfortable with uncertainty.

You might even start to crave uncertainty. That sounds masochistic, but I don’t see it as deriving pleasure from pain. It’s the calm before the storm. It’s the excitement of a potential discovery. This is the foundation of what I call “creative confidence”.

Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.

Subscribe now

Product: Problem Validation

Jen Abel

This is an important distinction. I’ve seen a lot of pitfalls from companies seeking product validation. It’s easy to ask a friend if a solution is good and get a false positive from someone offering words of encouragement.

You are less likely to get a false positive when asking if someone is experiencing a problem. It’s a less personal, more rational thought experiment.

It’s also important to appreciate the fact that your initial solution is likely to be garbage. Not always, sometimes companies hit the lotto on their v1. It is much more common that your v1 is suboptimal, and you get closer to a more optimal solution after many rounds of improvements.

So I agree. Early conversations should focus on validating the problem. It’s ok to also talk about solutions. That’s part of the improvement process. But validate problems, not solutions.

Figma: Design Specs

Vitaly Friedman

This is a neat tool. A lot of teams could produce better results with something like this.

I often worry about silo’ing the dev and design teams and essentially making the design team manage the dev team. I’ve always hated workflows that involve a non-collaborative spec handoff where design becomes a bottleneck for every change. This tool in those environments could get ugly.

If used in a healthier workflow involving a non-blocking design system, I see this helping a team get closer to pixel perfection without jamming the gears.

GraphQL: Network Inspector

Cory House & Yanko Valera

This has been one of my frustrations in troubleshooting GraphQL. Digging into GraphQL requests on the network tab in Chrome is tedious and very unintuitive. A simple extension to help name and organize requests can be life-changing.

CSS: Gradient Borders

Shripal Soni

This is a wonderful technique that can produce a beautiful gradient border in a few lines of code. Producing an effect like this used to involve a very ugly hack involving a bunch of images and some messy markup. It would have been difficult to pull off the 45deg gradient.

Discretion is advised: Old School CSS Round Corners

CSS: Tailwind Apply

Chris Sev

I seem to be in the minority on the Tailwind ‘apply’ debate. I don’t find the large acronym blobs to be visually parsable. The aversion to naming things in the Tailwind community is a little confusing. If you want someone to read your code and understand what the hell is going on, take the time to name things. Using ‘apply’ is much more semantic.

I do agree with Chris that JS components are an acceptable solution. The acronym blobs still live in components, but pages/views/layouts are much more readable.

Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.

Subscribe now

Product: PLG

Mari Luukkainen

I agree that product should be the hero. In fact, I’m restructuring my newsletter to lead with a product section. While product discussions are often nebulous and philosophical, I’ll share my take on what “product led growth” means more concretely.

Following the daily product discussion, I’ll cover 4 pragmatic skills and tools needed for startup generalists. Many skills will be user-centric, such as design, UX, and front-end development. But small teams have many needs. I’ll also cover backend, marketing, sales, fundraising, planning, and more. 💫

Sales: Outbound PLG

Justin Dorfman

I’ve been talking to Justin lately about product led growth and trying to understand how sales fits into a more sustainable PLG strategy. Freemium offerings are very appealing. I’ve always thought about it more as a marketing+product play. You start by building a self-serve freemium solution. Then use marketing to drive people to the top of the funnel. If the messaging resonates, they’ll sign up for a free trial and later upgrade if they get value.

Listening to Tito describe outbound PLG as a sales function makes me consider the importance of a sales/CS role in the process. Having a “product liaison” is particularly important when “inventing a new category”. When you invent a new category, it’s hard to drive inbound interest purely from marketing. People don’t realize a solution exists to a problem they face, so they are unlikely to search for it.

It’s often better to actively seek out the people who’d benefit. Talk to them about the problem to make them aware of the pain point. Then offer a free trial without any obligation. If they use the product, monitor their behavior and try to help them get more value. Then sell.

Design: Beauty & Utility

Vala Afshar

I often advocate for a function-first approach to design. Start with a scrappy solution that validates the utility, then iterate on the design and UX. This bridge is a good counter-example to show that utility-centric design is not always ideal, particularly in cases where you can’t easily retrofit a design.

The designers of this bridge didn’t have the option to start with a boring flat design, then add the waves in later. They had to take a risk. A much more complicated initial design that involved a more complicated engineering process requiring more material could easily backfire. Maybe this bridge required a 5x budget. The result could easily be unhappy users because it takes more effort to cross the bridge. But the upside is much higher than a boring bridge. This has the potential to be a tourist attraction.

I know nothing about the economics or decision-making that went into this design. But it’s a reminder not to be dogmatic in your approach to building things. Be flexible and willing to experiment and break the rules.

React: Project Structure

George Moller

I often use NextJS, which has an entirely different structure. But if I were to work on a React app with this structure, I’d feel reasonably confident that I could figure out what is going on without too much effort.

It might take a little time to get used to this structure if you come from an MVC (model view controller) background. It’s not immediately obvious where the views live, for example. But I’m personally not a fan of the MVC pattern. It’s just not intuitive to me where code should live. MVC proponents will say I’m wrong, and it is intuitive. I’ll save that rabbit hole for later.

What’s important when organizing anything is to name containers as unambiguously as possible. The fewer containers you have to open to find something, the better. I can imagine scenarios with this structure where I might need to open 3 folders to find a file. But I’d probably find what I’m looking for in the first folder 80% of the time. That would be a much better success rate than many codebases I’ve worked on.

Analytics: Vanity Metrics

Christian Blavier

First of all, congrats to Christian for setting a personal record! 🎉

Previously, I’ve been critical of vanity metrics. Sometimes it feels like ALL metrics are vanity and data-driven decision making is just a pipe dream. More recently, I’ve become a little more liberal in my view. It’s not a bad thing if a lot of data is used purely as a behavior-inspiring game mechanic.

Instead of being frustrated by vanity metrics on dashboards, we should appreciate that these numbers bring people to the data. It’s then our job to surround the flashy numbers with deeper insights.

Dane Lyons is a startup vet with hot takes and eclectic knowledge writing for the aspiring generalist.

Subscribe now

Design: Collaborative World Building

Kait Tremblay

Collaborative design is a fascinating topic. One of my favorite games of all time is still Minecraft. I remember playing with a group of friends and coming up with wild physics-defying ideas.

We’d collectively mine resources and contribute to the idea. But our visions were always at least slightly different. This required compromise, adaptation, and a lot of communication to arrive at something we were collectively happy with.

It’s nice to see modern design frameworks embrace a collaborative workflow. Figma and Miro are great examples that allow multiple designers to work simultaneously. I imagine game design is also moving more in the direction of collaboration. I’m just not as familiar with the tools.

Frontend: The :is Pseudo Selector

Ali

Using the :is pseudo selector nicely bundles a verbose list of selectors. I do think the more verbose format is probably easier to read/understand for contributors who aren’t CSS wizards. But I wouldn’t call the :is syntax unreadable. It’s just a new concept for a lot of people.

There are 2 alternatives:

1. The :not pseudo selector. If you have a particularly large list of selectors to match, it can be easier to list the selectors you don’t want to match.

.container :not(.bio){
  font-size: 24px;
}

2. Nested CSS. While nesting is not yet widely supported by browsers, I wouldn’t be surprised to see broad support in the near future.

.container {
  & h1,
  & a,
  & .btn {
    font-size: 24px;
  }
}

I don’t particularly like the “&” syntax of nesting. Hopefully, the spec changes to omit the extra “&” characters. If so, that’ll be my preferred method for bundling selectors.

Backend: TI-86

Colin

I’m surprised there is still a community of game developers hacking away on the TI-86! This was my intro to programming. I have a lot of fond memories of figuring things out without the internet to provide libraries or copy-and-paste snippets.

Kids writing code these days seem to have less resilience in problem-solving. They Google a solution as soon as they hit a wall.

Don’t get me wrong. I don’t believe there should be a right of passage requiring learning through a painful process of trial and error. Writing code should be highly accessible. A kid should be able to solve a real-world problem the first day they start writing code.

I’m frustrated because we are training the next generation to avoid hard problems. When we hit a wall, we should have the instinct to spend time thinking about it. Sometimes that process will inspire us to invent a new solution. Other times that process will help us arrive at the best available solution. Both outcomes are better than the instinct to use the first available solution.

Marketing: Swapstack

Swapstack

It’s nice to see change logs published for tools that aren’t dev-centric. I’d love to see that trend continue.

I’ll test Swapstack over the next few weeks to promote The Daily Subset. It’s nice to have access to small to mid-sized newsletters with approachable price points.

Team: Scrum Alternative

HTML All The Things & Mr. Steal Your Code

I’m not a Scrum fan. I know developers who love it, and others who hate it. I’m happy for teams that find their Scrum sprint groove. For me, it’s too formal.

I strongly prefer a simple Kanban workflow. Instead of everyone trying to break down work into 2-week chunks, members can operate at their own pace. People working on design and rapid prototypes might be working in 1-2 day cycles. People working on bigger infrastructure projects, might have 1+ month cycles.

Kanban also avoids story estimation which is one of my least favorite parts of Scrum. Investing time randomly guessing how long an ambiguous task might take…and being held accountable when you are wrong is potentially toxic. Some teams have a healthy story estimation workflow, but it seems kind of pointless to me. Instead of imagining how long something might take, just dive in and make progress.

Kanban isn’t perfect though. The todo items are often detached from an organizations North Star. If you just have a pile of things to work on without a notion of what’s important, it’s hard to make good time investments. A good Kanban process needs some notion of priority.

Dane Lyons is a startup vet with hot takes and eclectic knowledge writing for the aspiring generalist.

Subscribe now

Tools: Fig

Fig.io

I’m excited about the future of command line tools. The terminal used to be a cryptic space for backend wizardry. But companies like Fig are continually improving the developer experience. Each improvement makes writing commands more approachable. I hope we get to the point where the CLI a tool for backend wizardry and “no-code developers”.

I plan to turn Subset into a collection of open-source publishing tools. I’ll explore using Fig to do a lot of the heavy lifting for setup and configuration. I’ll share an update soon!

Design: Highlight Common Options

Naresh

It can be very frustrating to select a single option from a very long list. You can often narrow the list by typing, but that doesn’t always work well in practice. Being reasonably smart about showing what option will most likely be selected is a much nicer experience.

In the example of selecting a country, you could use javascript to detect the user’s preferred language.

navigator.language

You’ll get back a language tag. This can be used to map to suggested countries that are highly likely to be selected. For me, I get ‘en-US’, which maps to ‘United States’.

An even better solution would be to detect the preferred language and preselect the most likely option. Then the user doesn’t even have to interact with the selector if you are correct.

Development: React useReducer vs useState

David K.

People avoid useReducer because the useState syntax is more intuitive. I’ve certainly fallen into the trap of trying to update a complex data structure with a series of separate useState hooks. Updates get harder and harder to manage, and it’s easier to make mistakes.

I’d recommend useState for variables that are “independent” and useReducer for objects of interdependent properties.

const [darkMode, setDarkMode] = useState(false);
const [article, updateArticle] = useReducer(
  (data, partialData) => ({
    ...data,
    ...partialData
  }),
  { title: "", descrition: "", tags: [], status: "draft" }
);

Marketing: Content Calendar

Vourneen

I’m definitely in the “wing it” camp, mainly because I work independently. I assume content calendars are more common in larger teams requiring coordination.

This has me thinking about alternative solutions. Content calendars are a “safe solution” because they optimize for reliability. But what if you take less of a planning and more of an opportunistic approach to creating value? Teams that are “over-utilized” because their time has been preallocated through rigorous planning lose the ability to adapt.

I often think about bounty systems as a way of creating timely incentives without dictating how people invest their time. Some bounties could be safer long-term bets that might mimic content calendars today. i.e. create an asset for an upcoming holiday for $$.

But imagine if your team doesn’t feel tethered to the low-risk bets. Let’s say the next version of ChatGPT is released, creating an opportunity to be a leader in the ensuing conversation. So your team creates a bounty, “Write the ultimate guide to prompt hacking ChatGPT v2 for $$$$$”. Someone on the team should be free to drop everything and spend the next 48 hours putting together the internet’s go-to guide for the next 12+ months.

People should be free to shed prior obligations to pursue high-value opportunities.

Team: Recognition

Roberto Ferraro

Inspired by Valentine’s Day, I thought I’d cover the importance of recognition. I’m admittedly not great at giving positive reinforcement. It doesn’t occur to me that people might need it.

This stems from a self-reliance mindset. By default, I don’t tend to seek out external validation. In some ways, this is freeing, but it can also be isolating.

I’m not suggesting it is wrong to feel good when people say nice things. An over-dependence on external validation is probably unhealthy. But it’s perfectly natural to want to share your accomplishments.

Regardless of how you feel about recognition, it’s good to know people around you need it. It’s not hard to be generous with your words, just don’t be inauthentic. When someone accomplishes something, big or small, make it a point to show appreciation.

Design: Histograms

Infogram

I love histograms. They are often an excellent abstraction to a data set. If well-designed, they can convey so much information at a glance.

They can also be beautiful, like in this chart from Infogram. It could be simplified to convey similar information in a fraction of the space. But if you want to make it the centerpiece in a magazine or a web page, go nuts. A highly visual implementation certainly grabs a reader’s attention.

Subscribe now

Frontend: P5js Guides

Orr Kislev

P5js is my preferred library for building custom interactive data visualization on the web. Sometimes it can be challenging to mentally keep track of the underlying grid as you transform shapes. Seeing the guide lines could be really useful while developing.

Although I find the demo to be disorienting because it dives straight into a complex example. I’d like to see a simpler demo with and without the guides.

Share The Daily Subset

Backend: DNS

Valdemar

DNS will never make sense to me. I’d rather fight regex battles than try and figure out why a domain configuration isn’t working. I think the frustrating thing for me is the painfully slow feedback loop. You make a change and have to wait an undetermined period of time to see if it worked.

It’s helpful to see how the underlying system is designed. I’d love to see a visual troubleshooting guide. When you run pings and other commands, how does information flow through the system to give you a response?

While my daily work depends on DNS, it’s hard to justify taking a deeper dive. It’s a reliable abstraction that works well when you get the config right. I hope DNS evolves to be a little more bulletproof and transparent. Until then, thanks to people like Valdemar for helping keep systems connected! 🍻

Subscribe now

Marketing: Emotional Responses

lindsay

I agree with Lindsay. It should be rare for individuals to be held accountable for using words that trigger negative emotional responses. By setting that expectation, we discourage dialog. This is particularly worrying because people are now avoiding the hard discussions necessary to lay the groundwork for a more equitable society.

I also agree that words should not be used as inflammatory weapons. There are a lot of words that we collectively agree are inflammatory. It’s good to be thoughtful in our use of those words.

But I didn’t seek out this tweet because I wanted to rant about modern society placing limits on our vocabularies. I’m much more interested in how words can inspire a positive emotional response.

In marketing, we should try to predict an audience’s emotional response to a collection of words. That response should be in line with the brand identity. This is not malicious, it’s thoughtful communication.

I had a discussion with Grammarly last year about the topic.

With that data, it would be amazing to create criteria for a brand identity. Maybe you want a brand that is “friendly, fun, and smart”. Then you could use data to highlight words in a draft document that either reinforces or violates your brand words. By maximizing highlighted green words and minimizing red words, you increase the probability of a positive emotional response.

Share The Daily Subset

Team: Home Offices

miggi

With so many teams going remote, I’d love to see companies increase budgets for contributors to beef up their home offices. This is where people will spend most of their time in 2023. They should be working in spaces that are comfortable, ergonomic, and inspiring.

My personal space is a dungeon, so I won’t be sharing photos anytime soon. But I’d love to redesign it at some point.

Design: AI Assisted Design

Ben Blaiszik

It’s a natural evolution to go from AI generated art to AI generated interfaces. What I’d like to see is an AI assisted design workflow. Here’s what I have in mind:

1. A human provides the v1 design. This could be as simple as a napkin sketch or as complicated as a coded functional prototype.

2. AI takes the initial design along with prompts suggesting the direction the team would like to take the design.

3. AI provides a collection of variants that iterate on the initial design using the prompts as a guide.

4. The team takes a promising variant and marks it up with suggested improvements, and adjusts the prompt.

5. Steps 3 and 4 are repeated to refine the design until the team is happy with the results.

Share The Daily Subset

Frontend: Reactive Shaders

Manoela Ilic

It’s amazing to see what browsers can do these days with WebGL.

Taking real-time data from an audio source and applying it to a shader might seem like a “neat trick” with no real-world application. To that, I’d say:

1. Art is a real-world application.

2. Adding techniques like this to your tool belt can come in handy in unexpected ways. Maybe one day, you find yourself working with streaming data from weather instruments. You need to find a way to make sense of it, and the static visualizations just aren’t cutting it. Suddenly you remember this tutorial and realize you can use Three.js to create a more dynamic visualization.

Subscribe now

Backend: Continuous Deployments

Jimmy Cleveland

I’m a big fan of Vercel. I’m able to spend the majority of my time thinking about how my apps are designed and function without worrying about all of the supporting infrastructure that helps get my code from my personal laptop to the internet.

Even though Vercel automates everything for my preferred NextJS tech stack, it is still useful to take a deeper dive into continuous deployments. Jimmy walks you through using Vercel to deploy a minimal webpack javascript app. It’s particularly useful to see how preview deployments work on feature branches.

Share The Daily Subset

Marketing: Honing Your Style

Bryan Hutchinson

What I like about this tip is the emphasis on YOUR attention. You are not offloading your evaluation of “what is good” to the crowd or an external authority. This allows you to learn from the output of others while honing your personal style.

In addition to benefits to your writing and style, general awareness is living. Don’t shut yourself off to the outside world. Take it in.

Subscribe now

Team: Design Everything

Tony Fadell

The realization that you are not restricted by established conventions should be a freeing sensation. Your process, brand, schedule, work environment, revenue model, and everything in between is waiting to be designed or redesigned.

Each design is an opportunity to improve in some area. A simple shift can reduce cost, increase revenue, improve moral, add trust, or reduce effort.

This might feel overwhelming, but you don’t have to design everything at once. Do one thing at a time. Focus on making a single improvement, then move on to the next design opportunity.

Design: Empathy Gap

Dr. Pete Meyers

The empathy gap is an important concept related to UX design that doesn’t get enough attention. When I search “empathy gap ux” in Twitter, here is one of the few relevant tweets from Dr. Pete Meyers. It’s from 2018!

Designers tend to use more informal language to describe the concept. You can probably find 5k tweets daily about people saying, “talk to your users”. That is essentially saying, “gather more information about your users to help close the empathy gap”. This is good, it’s the foundation for user-centered design (UCD).

The problem that I have with the empathy gap is the underlying assumption that the more empathy, the better. The more pain you feel on behalf of an individual user when they experience friction within your app, the more motivated you are to put on blinders and do whatever it takes to relieve that pain.

There is an opportunity cost to focusing on an individual’s pain.

It forces your team into a reactive mindset that neglects the collective pain. Understanding and addressing the collective pain should be the focal point of a small team with limited time.

To rally around the collective pain, I believe it’s important to do the cliche “talk to your users”. The more information you gather, the more you close the cognitive empathy gap. This means you can think from your user’s perspectives and intellectually understand their problems.

It’s also important to avoid biases created by closing the affective empathy gap. It’s ok to feel an individual user’s pain. But it’s a good practice to put a little time between feeling the pain and reacting to it, even if it’s only a few hours. This allows you to step back and think more rationally about how you are investing your time.

Being rational instead of emotional doesn’t mean you shouldn’t communicate with compassion. Be open and honest and say, “I feel your pain. A fix is realistically at least a few months away. Here is a hack you might consider…”

Share The Daily Subset

Frontend: Description Lists

Emma Dawson

Semantic markup goes beyond organization and style, it lends context to your content. The next time you define a term in your content, consider going beyond basic <div> and <p> tags. My preference would probably be the <dfn>, <dl>, <dd>, and <dt> tags.

I do wish browsers would have created a different convention for definitions. More verbose tags would be more intuitive than acronyms. The role=term or role=definition is more verbose but less clean. 😭

Subscribe now

Backend: Gelato

Gelato

This is an exciting development in web3 land! The ability to create decentralized cloud functions should open the door for new use cases.

My first thought is wondering if this might be compatible with oracles to trigger contracts based on off-chain events. Clicking the discover tab on Gelato brings up a lot of functions with oracle in the name, so I assume this is useful for oracles.

Here is a more in-depth description of what Gelato is, along with documentation.

Share The Daily Subset

Marketing: The Sample

The Sample

As an indie writer, I want to make my content discoverable without shoving it down people’s throats via spam. So the concept of The Sample resonates with me. I can focus on content while they match up my words with readers.

I just integrated their app, so we’ll see how it works. I may post a follow-up with my thoughts on their analytics and overall service soon. 🖖

Subscribe now

Team: Work Events

Adam Grant

I completely agree with Adam. The relationship between an employee and a company is often unhealthy. Companies should not act as if paying a salary means they own the time of their employees and can use it at their discretion. That setup is oppressive and should inspire quiet quitting.

The goal should be to create more of a partnership based on respect and aligned interests. A relationship based on respect does not involve unilateral decisions that create obligations. People should be trusted to act on behalf of the company, not forced to do so. Dinners, meetings, and everything in between should be 100% optional.

Design: Live Training

Gergely Orosz

This is a problem with enterprise SaaS. Growing startups want to be that all-in-one solution, requiring a tangled rat’s nest of functionality. Live training is the bandaid solution because it’s hard to provide a good user experience as the product grows in complexity.

Companies should focus on making the core use case as obvious as possible. The onboarding experience should be about getting from A to B without being distracted by a side quest. Once users have that foundation, introduce them to a plugin marketplace to tack on value add features.

Share The Daily Subset

Frontend: Centering Things

freeCodeCamp.org

Centering things in CSS used to be complicated. You used to have to use unintuitive margin or position hacks. I still occasionally use a position+transform hack if I’m doing something uncommon. I use flexbox to center things 95% of the time.

/* parent */
display: flex;
align-items: center;
justify-content: center;

Even if you do use flexbox, I’d recommend reading that article. It’s useful to know other techniques. When you encounter that code in the wild, you’ll know what is going on.

Subscribe now

Backend: Cheat Sheets

Rohan Paul

It has been a while since I've written SQL. I’ve worked primarily with NoSQL solutions and key/value stores more recently. In the future, I’d love to explore vector databases.

Even if I’m not writing SQL today, it’s likely I’ll need revisit that skillset at some point. These cheat sheets are so valuable. Five minutes of reading through a well designed cheat sheet can save hours of Googling.

I’d love to have access to cheat sheets for every technology I’ve ever used or plan to use. Thinking about this makes me want to design a book of cheat sheets. Imagine a 300 page book covering 150 technologies. Every technology gets 2 pages so you can lay the book flat and see everything.

Share The Daily Subset

Marketing: Sponsor Ninja

Vincent Will

Self-serve sponsorship opportunities are very interesting to me. I’d much rather pay $5-10 for a low-friction sponsorship that has the potential to drive brand awareness and dozens of clicks over the lifetime of the ad than investing $5 in a single click through PPC.

As I build the next iteration of Subset, I plan to create a resource hub for self-serve sponsorship options. Apps that integrate Sponsor Ninja will be a nice starting point. I even have a domain for the project. (sponsified.com 😎)

Subscribe now

Team: Managers of One

Mohammed Furqan

My wife is reading Rework currently. I’ve always been inspired by the the 37signals crew, Jason Fried in particular. They are pioneers of doing more with less. Hiring managers of one is a perfect example. You don’t need a crazy hierarchy of people owning other people’s time if you can find and inspire people to be autonomous contributors.