Skip to content

Instantly share code, notes, and snippets.

Last active April 16, 2024 11:55
Show Gist options
  • Save davestewart/643ffc55aa7c173618d2707b776a1443 to your computer and use it in GitHub Desktop.
Save davestewart/643ffc55aa7c173618d2707b776a1443 to your computer and use it in GitHub Desktop.


This document is an attempt to pin down all the things you don't think about when quoting for a project, and hopefully provide a starting point for some kind of framework to make quoting, working and delivering small-medium jobs more predictable and less stressful.



The hardest bit of any job, and lots of pitfalls

Estimating the work

  • the actual work of what you see on screen will only be a fraction of the work to do
  • you can estimate the steps needed "to do a thing" but not always the complexity of the steps
  • don't underestimate "the work to do the work", "the work between the work" and "the work around the work"

Price for value

  • if you can do something others can't, price accordingly
  • if the hassle for the client starting again, or going elsewhere is prohibitive, price accordingly


You need to account for working with unfamiliar services

Domain knowledge

  • multi-domain or multi-dependency projects are more difficult (naming, objects, APIs, etc)

Do you know the technology?

  • knowing something exists is very different from knowing it inside out
  • it may be difficult or even extremely difficult to learn, meaning you spend a long time writing bad code
  • it may turn out to be unsuitable after all
  • you may not properly learn it and create a mess which will need to be cleared up at some point

Picking the right technology

  • Nuxt vs Vue
  • Elastic vs Postgres
  • Azure vs ???


You may be skilled, but it's highly unlikely you will know everything you need to

You won't know what you don't know

  • you may need to learn new skills (elastic, nuxt, some api, etc)
  • you may not know this until it comes time to actually do the work
  • this could significantly impact your timelines / profit margins / client relationship
  • is there any way to predict this in advance?

Your current skills may be adequate for small but not medium or large jobs

  • relying on basic skills may get you over the line, or may bite you later in the project
  • how should you tackle this? Level up? Subcontract? Who will pay for this?

Unforeseen problems

  • you will underestimate the difficulty of some tasks
  • you will underestimate the timings on some tasks
  • you may have showstoppers where you can't go on
  • how should you predict / manage / cost for these?

Third party tools

  • save time by using something already made for the job
  • note that depending on the scale of the tool, it will still take time to learn

First party tools

  • sometimes, you have to build it yourself
  • time saved learning something else may be taken up in planning, development, debugging, refactoring, packaging, documenting
  • a tool could take a few days or a few weeks, and will require ongoing maintenance and updates

Preparation (the work before the work)

You need to put a lot of things in place before you can do the actual work

Project setup (these could all be separate sections!)

  • config and build setup
  • keys and security
  • 3rd-party dependencies
  • component library
  • initial folder structure
  • routing and layouts
  • Api
  • login and logout
  • store and state
  • additional services
  • individual utilities
  • repositories and deployment



  • new layouts to think about
  • the ui kit does not account for many use cases, and does not cover layout
  • figuring out how all the ui components should fit together in your layout may take longer
  • compound UI components may take longer

Also see "the work between the work"


POC is completely different from something the client / users will be happy with

Developing the actual code (utility, library, service, component, feature, module, app)

  • POC is bare minimum to show it can work, crap UI, can only be used by devs
  • Alpha is first rough working version, that can be used by (brave!) humans
  • Beta / MVC is mainly working, but there may be bugs
  • Release is working, big-free, polished, potentially documented and with tests

Getting the details right takes time

  • the 80/20 rule of getting things perfect
  • changing your mind or making something better
  • realising that you were doing it wrong
  • iterating (getting it working, vs getting it right) to the best solution
  • keeping things consistent


  • API with notifications
  • form interaction
  • form validation
  • modals

Stuff that if it wasn't there would look broken

  • empty states
  • loading indicators
  • error handling
  • notifications

Design and finish

  • adding the polish to make it look nice
  • fixing bugs which may or may not be your fault

Quality control

  • adding tests
  • adding support like storybook
  • writing documentation

Iteration (the work between the work)

Any project longer than a few weeks has invisible costs built in

Note: these kinds of changes are invisible to the client!


  • your own code because it's not working as expected
  • third party code or configuration because it doesn't support something you need


  • updating or fixing configuration
  • keeping up with framework changes and patches


  • updating build tools to make things faster / more reliable
  • building dev tools to help you do the work
  • introducing new processes and tools

General maintenance as you go along

  • building systems to keep things DRY


  • could be database, services, anything
  • planning a migration
  • running two sets of code
  • implementing the migration


  • stitch-in-time updates (even if out of scope) so it doesn't turn to shit
  • larger refactors to prevent spaghetti or make hard things possible
  • updating older systems as you find bugs or expand functionality


  • as requirements change, you may even need to take functionality out!
  • removing complexity can sometimes be as hard as adding it


  • what is works in once place today, may not work in two places tomorrow
  • new layouts or components may be required (dropdown, modal, notification)
  • as the app gets more advanced, more components will be expected to work together



  • expectation management / negotiation (over or under / difference of opinion)
  • omissions


  • client changes
  • feature creep
  • mission creep


Larger projects have different constraints and inherent increased complexity vs small projects

Going from small to medium

  • think about thresholds when going from a simple app to a complex app (routing, store, tools, etc, etc)
  • once the application grows, consistency is an issue; adding new layouts to old, keeping track of components
  • you'll need to scale up things like naming conventions, css file structure, store paths, etc
  • taking time to make the styling consistent as it scales

Increased size will (in part) mean increased complexity

  • complexity can increase as more features are added ((n*(n+1))/2)
  • coupled features means more dependencies
  • something which was quick to edit at a small scale may slow down as the project grows
  • need to account for more time moving between sections of the application


  • shortcuts taken in a small project will likely not scale well in a larger project
  • for example, window.prompt, password protected folders,


  • meaning folders, routes, APIs
  • as the app grows you may need to introduce additional levels


  • local state is easy, but not flexible
  • need to access same state from two different places? Make it global
  • the calls and format will be different
  • you may need additional tooling like Vuex Pathify
  • or, it may bemore complex than a simple vuex store
  • might need to build services, use a new technology, or something else


  • initial state / loading
  • saving the data
  • loading the data
  • using cookies, localstorage, URL, database

Things you could get away with in a small project, you might not in a big project

  • updating the URL with form changes

Admin (the work around the work)

There will always be a significant amount of work around the work


  • reading docs
  • trying out libraries
  • code sketches

Internal work

  • code reviews
  • writing issues
  • repository management

Client management

  • meetings
  • reviews

Support (the work after the work)

Once the project is live, or nearly live, there is still work to do


  • hosting
  • deployment
  • updates / upgrades
  • bug fixes
  • security


The "* work" analogy

Often the "work" is only a fraction of the work.

Phrase Meaning
The work to get the work Planning, quoting, pitching
The work before the work Setup, configuration, prototyping
The work The actual build, product, etc
The work between the work Debugging, development, refactoring, tooling, maintenance
The work beyond the work Omissions, scope creep, mission creep
The work around the work Client meetings, code reviews, project management, etc
The work after the work Hosting, deployment, support, security

See final article here.

Copy link

Great insights! I really like organizing around the work to do the work, the work between the work and the work around the work. It's a unique take -- but very sensible. Here are suggestions that might fit in the "The work around the work" or "Requirements" section:

  • Consider adding more detail on duration. Although it's mentioned in The Work Between the Work, the length of an engagement usually correlates directly with the risk of a bad estimate. I almost feel like you could write separate articles for short- vs. longer-term projects. Maybe a note about how/when a short-term dev project turns into a long-term project and how to consider this possibility when preparing your estimate.

  • Maybe a section about estimating by project phases -- breaking up a large estimate into smaller phases that are easier to estimate. Webdev projects tend to have clearly defined phases.

  • Mention the importance of client sign-off to signify the closure of a phase and protect against feaure creep.

Copy link

davestewart commented Dec 16, 2021


I realised that there's probably also "the work after the work" which is hosting, support, security, etc, etc. Not sure how far this analogy can go, but it does make sense.

Good suggestions as well. I will think about how to add them in.

I feel like the overall "project management" side of things could be a separate article; my thoughts so far have mainly been about identifying the physical nuts and bolts rather than how to organise the delivery of them.

Copy link

I think the analogy works well, but I'm also partial to analogies :). A few other opinions on this might be good.

Maybe you can work in a bit of the project management content as related to estimation, defining scope, and managing expectations. Otherwise, you can probably link to a few good project management articles for those interested, since PM tends to be a rabbit hole with endless theories and points of view.

Copy link

@richeklein analogy updated! Check the Notes section

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment