Cheatsheet
You can print this page to PDF.Management and Planning
Decide if it's a business or a hobby
When running a business, decisions made must be in its best interest. When working on a hobby, you can do whatever you feel like on that morning.
Don't drink the Koolaid
Keep your head down and focus on the business, not on reputation building.
Building a marketplace is like training for a marathon
You need to operate at near maximum, but not quite, for very long.
Investor value of a marketplace
It comes from owning the transaction and being difficult to replace.
The tech roadmap should follow the business roadmap
It should be very flexible to changing requirements.
Bug priorities should relate to your ability to collect money
The more your ability to collect money is impacted, the higher the priority.
Focus on what if it succeeds
Do not plan prematurely plan for contingencies and split your focus.
Keep track of why decisions were made and features built
This will help you keep track of original reasoning when the feature was built and allow you to see if the circumstances have changed enough to further develop something.
You're not FAANG so don't hire like FAANG
You are not looking for the same things and you cannot offer the same things.
Take hiring seriously
You should consider it a key task and put in effort.
Don't create silos
It's better for everyone to know what's happening.
What it really means to make data-driven decisions
Gathering as much correct data as possible, constantly reviewing decisions and being able to tell signal from noise.
Mistakes to avoid when assigning ownership of metrics
Incorrectly assigning ownership of a metric hurts the business as well as the person who can't affect it properly
Get good at cohort analysis
It's one of the most useful tools and will be used for due diligence as well.
Removing things is good
Things that aren't working should be removed and not maintained further.
Be careful with customization for a particular client
It rarely pays off.
Convert, grandfather or alienate
Three approaches to handling changes that users might not be happy about.
Product
Lessons when designing the product.
Deciding what not to build is nearly as important
A gauntlet of questions to decide whether a new initiative is worth it
Two approaches to product design
Help the user do what they want, or make them do something you want. If you find yourself focusing on the second, your business is in trouble.
Copy blatantly
Instead of redesigning standard features, pick comparable role models and copy theirs.
Minimum viable process
Software is a supporting component in a process that accomplishes something useful more efficiently than others.
You might get customers that you weren't planning on
Listen closely to their feedback because they are actively looking for a solution to a problem.
Understand your value to your users
Make sure that you know all the benefits of what you're selling, not just what you intended.
Don't overreact to weak signals
It makes you build poorly thought out and potentially wrong things.
Not everyone's opinion is equal
Don't ask an accountant about routing algorithms.
Learn the correct jargon and use it consistently
To effectively communicate with your team and customers, you must learn the correct jargon and use it consistently.
Observed users personas
When you are observing users interacting with your app, they take on a different persona
Don't half-ass many things
Half-ass one thing many times.
Think about how new things can affect what you already have
In particular, consider whether new things you're working on can destroy what you've already built.
Consider the complementary interaction
Sometimes creating the opposite interaction can have an even more powerful effect
Internal product management directly improves your company's efficiency
Your team should be given a similar level of attention as your external users.
Separate the trackers for admins
That way main user data won't be polluted, but you'll still have a window into what the admins are doing.
Each job should have a custom dashboard
That dashboard would show all and only the information and actions that they need.
Build a simple flexible dashboard for viewing stats over time
Include the ability to select start and end dates, period lengths, and the number of periods prior and following.
Simple user permissions are very useful
They're not just about control but also a tool to design a simpler and less error-prone product.
Technical
Add spellcheck
A very easy quick win that many marketplaces neglect
Store all calls from APIs
If you enable webhooks for a service, store all their calls regardless of whether you consider them 'useful'
Build polite software
The principle of polite software is a great cheatsheet while improving your product design skills.
Take security seriously while you're small and no one is likely to exploit you
Using a static analysis tool that scans for vulnerabilities is a great help for this.
Take testing seriously as you go
It's much easier to build it in step with the platform rather than having to backfill later.
Take performance seriously while it can't cripple you
Premature optimization might be the root of all evil, but performance often means just not being lazy.
Use an error tracking tool as early as possible
A central place where you can trace errors, track their progress and easily identify regressions becomes valuable very early on.
Implement a background task processing structure
It's a pre-requisite in some cases, a nice to have in others, but it also gives you better bang for your buck when it comes to hosting.
You can get quite far with a small tech team
You're likely not innovating on tech but rather on the underlying process. So you should hire for people familiar with your niche and tools.
Write docs religiously or not at all
The best way to write docs is any way that makes you do it consistently. The second-best way is not to.
Consider adding these attributes for every new model
These are some common attributes that we've found to be useful to include in many models.
User interface elements should behave consistently
It is important for UX but also removes the need to think about them during implementation.
Generate more data than you think you'll need
Build in tracking for things in advance even if you think you won't use them because data is the first step towards developing something new.
Know when to denormalize columns
Store and sync derived columns that are frequently accessed or that you need a historical record of.
Maintain a hierarchial structure for settings
Often the ideal structure involves three levels: system, group, and individual. The setting should be picked up in reverse order.
Have admin editable platform settings from the start
Don't only avoid magic numbers but avoid constants entirely.
Implement an audit log
It's just needs setting up once and is useful for a few different things.
If dealing with money get as close as possible to double entry bookkeeping
That way you will be able to track incoming and outgoing from the start, immediately be able to reconcile, give finance a proper insight and make due diligence easier down the line.
Build and use a robust import feature
Make a robust import feature that can be used for different entries.
Build and use a robust export feature
Use a library for exporting your index views to XLS or CSV.
Give admins the ability to comment on everything
It will be very helpful as a central store of operational knowledge that survives team changes.
Admins need fudgability
This ranges from being able to edit individual order values to being able to perform tasks on users' behalf.
Use fewer tools but more completely
Their features are nearly identical, they all have advantages and disadvantages. Pick the one most of your people are familiar with.
Be prepared to roll features out in stages
Features that are used frequently, impact sales or are complex should be rolled out in phases rather than to everyone at once.
If the changes you're working on will require downtime, split them into two
One part should be the migration while the other implements the functionality. They should be deployable independently.
Use different keys for different parts of the cache
So you won't needlessly invalidate large parts of your cache
Users double click everything
Make sure that duplicate actions aren't destructive or that they cannot be done in the first place.
Build stats beginning with the rows
Instead of querying the stats first, join it with the rows that you have to have.
Create a separate stat model
You can track stats independently and not have to keep adding columns to the main operation models.
Async selects are easy performance wins
Implement a re-usable structure that can be used for different models.
Further Reading
Contributing
Ways to contribute
Roadmap
A loose roadmap of what I'll work on next