Technical

This chapter covers lessons learnt in code or architecture. It is most useful for the CTO.

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.