Processes keep the project predictable

• [ ] Set up a team in Linear and train everyone on using it for task lists
• [ ] Daily Check-Ins to build and maintain shared understanding
• [ ] Post-launch engineer rotation Every day, the team designates a 'first responder' engineer who will be made known to the client's lead contact responsible for digital. They'll triage any incoming requests outside of the normal project life cycle, like critical errors, and pull in other team members as required.

See also:

• The Structure of a Projects

  Gather project resources early and get collaborators to think about the last things first

• [ ] As early as possible, get access to all required tools, so that we aren't blocked on building midway.
  • DNS
  • CRM
  • Zapier
  • Facebook / Google Analytics
• [ ] Get brand assets
  • [ ] Source files
  • [ ] Fonts
    • [ ] Design — download?
    • [ ] Web — typekit?
• [ ] Ask them to start generating copy as they will have an internal team workflow for clarifying what they want to say
  • [ ] Agree a Copy → Implementation workflow

Engineering

Start with a live product and stay that way throughout

• [ ] Agree URLs
  • [ ] Decide a DNS strategy early and then plan the timelines for switch over and resolving the changes
• [ ] Get deploys set up first things first
• [ ] Get a 0 → develop README up second

  Consider how the system integrates with the campaign's ecosystem

• [ ] CRM set up
  • [ ] URL query parameters
  • [ ] CRM tag definition and mapping
• [ ] Set up Analytics
  • [ ] Campaign UTMs
  • [ ] Funnel analytics
  • [ ] Train them on using the analytics platforms if required

    Standard user stories

• [ ] Share card: user can share URL on social media and attract clicks How are decent share cards going to be produced?
  • [ ] Share card graphic needs to be designed

    Predict post-launch service and prepare for it

• [ ] Enough error logging to enable a bugfix We add this in so that, if anything goes wrong, we have the tools to inspect them. Think especially about integrations.

  Create consensus when foundational libraries and frameworks are installed

On a greenfield project, lots of decisions need to be made that affect feature development. Foundational libraries and frameworks determine how most other work will be done, such as styling, theming or UI component library system which will apply to pretty much any new user interface code.

Everyone has technologies they are most comfortable/efficient at working with, and there's often also a few "cool new" technologies that people want to try out too. Striking a balance between working easy and trying things out should involve a consideration of project risk and developer consent.

It's typical to start building on a single branch until these decisions have been made. After the framework of the app is clear, it's then safe to switch to PR-based development.

Commonly, consensus is useful around issues of:

• [ ] Repository We almost always create a new repo in github.com/commonknowledge but this might be different if the team we're working with has their own repo.
• [ ] Server-side We often use django serving static HTML, using a postgres
• [ ] Hosting and environments We have a penchant for heroku with staging and production environments in a pipeline, both running "production" builds so we can test things as much as possible on staging. If possible, we try to inject environment variables at the very last moment, so that we can "promote to production." We'll normally provision a postgres database: when we do this it's useful to set it up on a hobby basic plan from the beginning to avoid the row count limit of a free plan and the faff of having to migrate later.
• [ ] Client and build system We almost always choose react and typescript but it's worth double-checking. If we're using something like Django, we'll have a separate webpack build system and an integration. We've done that a lot.
• [ ] UI components Often we'll use off-the-shelf libraries to help us bootstrap. Consider:
  • Accessibility
  • Theming
• [ ] Styling/CSS Nowadays we're using tailwind because it works in raw HTML as well as JSX, can turn Figma design systems into class names quite quickly etc.
• [ ] Schemas and forms
  • Form schema systems like zod or superstruct or yup
  • Form library (something like react-hook-form or react-jeff)
• [ ] Routing Often react-router but it depends