A Day-1 Build moves quickly because the scope is narrow.
We’re not asking you to arrive with a detailed brief, a process map or a set of screen designs. We’re asking you to bring the job your team is already trying to manage.
That job may sit in a spreadsheet, a shared mailbox, an old Access database, a paper form, a folder of documents or one person’s head.
The better we can see how that job works today, the easier it is to build something your team can start using.
Bring one job, not the whole business
A Day-1 Build works best when the target is specific.
Not “we need to improve operations”.
Something closer to:
- tracking customer requests
- managing quote follow-up
- logging site visits
- handling training bookings
- chasing supplier information
- keeping track of approvals
- managing a small stock, asset or equipment list
- replacing an old internal database
- making a regular report easier to produce
- organising work spread across emails, files and spreadsheets
The job should already be causing friction. People chase it, copy it, check it, re-key it, explain it, or worry that one person knows too much about it.
It also needs to be contained enough for a first working version to be built in one focused day.
If you’re unsure what kind of job fits, our examples of systems we’ve built show the pattern. Different businesses, different details, same underlying problem: an important job has become harder to manage than it should be.
Bring the current version
The current version doesn’t need to be tidy.
In many cases, the messy parts are the reason the build is worth discussing.
Bring whatever exists now:
- the spreadsheet people update
- the shared mailbox where requests arrive
- the form staff fill in
- the Word document or PDF that gets copied each time
- the folder where files are saved
- the report someone rebuilds before a meeting
- the old Access database or internal tool people still depend on
- the notes that explain what happens next
A written summary can make the job sound neater than it really is. The current version shows the details people deal with day to day.
Bring examples from the work
Examples help the day move faster.
Not perfect sample records. Actual ones from the business.
For example:
- a normal job or request
- one that needed chasing
- one that was completed
- one that was cancelled or changed
- one where information was missing
- one where someone had to ask, “Where are we up to?”
Those examples help us see the records, statuses, steps, handovers and exceptions the first version needs to handle.
They also stop the day being based on guesses.
Bring the person who knows the job
The right person isn’t always the owner or director.
For many Day-1 Build projects, the person who knows the job best is the person who updates the tracker, checks the emails, prepares the report, chases the missing details or explains the process to everyone else.
That person can tell us things a document may miss:
- which fields staff skip
- which status labels cause confusion
- where mistakes creep in
- what people ask for again and again
- which exceptions happen in practice
- what would make the first version easier to use
A senior decision-maker may still need to be involved, especially where access, reporting or business rules are concerned. But the person doing the work shouldn’t be left out of the conversation.
Have someone available to make decisions on the day
A one-day build needs quick decisions.
That doesn’t mean rushing big commercial choices. It means having someone available who can answer practical questions:
- What should this field be called?
- Is this status still needed?
- Who should be able to see this record?
- Should this be required before the record can move forward?
- What should appear in the list view?
- Which report or export would help first?
If every decision has to wait for a separate meeting, the day loses pace.
The best setup is simple: involve the person who understands the job and make sure someone with authority can settle small decisions as they appear.
Know what the first version needs to make clearer
A Day-1 Build shouldn’t try to absorb every future idea.
The first version should make one job easier to see, update and trust.
That might mean:
- everyone can see the status of each job
- customer requests no longer sit only in an inbox
- quotes have a clearer follow-up route
- files are linked to the right record
- missing information is easier to spot
- a manager can see progress without asking for a manual update
- a repeated report no longer has to be rebuilt from scratch
This is where focus helps. The first build should solve the important part of the job, not turn into a wish list for everything the business may want later.
Park what can wait
Some ideas belong in the first day. Some can wait.
A first version may not need every report, export, automation, notification, integration or edge case. If those things are needed later, they can be considered once the first system is in use.
The goal is to finish the day with something your team can start using, not a half-built version of a much larger project.
That is why choosing the right first job is important.
What to bring before the day
In practical terms, this is enough for a strong start:
- one job to focus on
- the current spreadsheet, inbox, database, form, notes or files
- a few examples showing straightforward and messy cases
- the person who understands the job
- someone who can make practical decisions on the day
- a clear view of what the first version needs to make easier
You don’t need to turn that into a formal specification. We can shape the system with you.
The better starting point is the job itself: what happens now, where people lose time, what needs to be clearer, and what your team would need in front of them to start using a better way.
The question to ask before you book
Before booking a Day-1 Build, ask this:
Which job would make the business easier to run if it had a clearer system around it?
If you can point to that job, show how it works now, and bring a few examples, you’re closer than you may think.
Bring us the tracker, handover, approval, report, old database or admin process that is taking too much effort or causing too much worry. We’ll tell you whether it fits a Day-1 Build, needs a different route, or should wait until the problem is clearer.