The price covers the focused build agreed before the day. You shouldn’t discover afterwards that it was only the first instalment of a larger project.
The aim of a Day-1 Build is to finish the day with a live system for the specific job agreed beforehand. Your team should have a clear place to record the work, see what is happening and handle the important steps.
That doesn’t mean squeezing every report, integration, historic exception or possible future idea into one day. It means choosing the scope carefully enough to build a first version your team can start using.
Before committing, it’s reasonable to ask what happens next.
Will the system be ready for real work? What happens if you notice something after the build? Will you be expected to commission more development? Can you move the system elsewhere if you want to?
Will you be left with half a system?
No. A Day-1 Build should leave you with a working system for the job agreed at the start.
You receive a working application, rather than a mock-up, a collection of proposed screens or a demonstration that still needs a separate project before anyone can use it.
During the day, we focus on the parts needed to make that job work. Depending on the process, that may include:
- the information your team needs to record
- forms for adding and updating it
- lists showing the current work
- the stages each record moves through
- who can see or change particular information
- existing data that needs to be brought across
- an immediate report, view or export
- the main checks needed to keep the records accurate and clear
The scope is deliberately contained. We don’t try to rebuild every connected part of your business or cover years of unusual cases before anyone can enter the first record.
This focus allows the agreed job to be put into a usable system instead of leaving you with a large piece of unfinished work.
What happens to your spreadsheet, inbox or old system?
The existing information doesn’t have to disappear when the new system goes live.
You may still need the old spreadsheet, shared inbox, database, documents or paper records for reference. Some information may be brought into the new system during the build, while older material remains available separately.
If you’re preparing for the build, what to bring before a Day-1 Build explains which examples, records and people will help the day move faster.
The important decision is where new work should be handled.
If staff add some records to the new system and continue putting others into the spreadsheet or inbox, the business can end up with two versions of the truth.
Part of putting the new system into use is agreeing when the old method stops being the place where day-to-day work is managed.
That doesn’t mean deleting your history. It means giving the live work one clear home.
What if you notice something after people start using it?
Real use can expose details that were difficult to see beforehand.
A label may be unclear. An important item may need to appear higher in a list. Staff may discover that an agreed step behaves differently when they use it with a real customer, job or request.
You can still raise questions after the build day.
There are three different situations:
- Something in the agreed system isn’t working correctly.
- Something agreed for the build has been missed or misunderstood.
- Using the system has produced a new idea.
Every Day-1 Build includes a 30-day settling-in period from the date the system goes live. During that time, we’ll fix anything that isn’t working as agreed and make reasonable small adjustments where real use shows that something minor needs changing.
You only need to raise the point within those 30 days. Any agreed correction can be completed afterwards.
This doesn’t include new features or larger changes to the agreed scope. We’ll discuss and price those separately before doing any additional work.
A new idea may improve the system, but that doesn’t mean the original system has failed or the change must be made immediately.
You can decide whether the idea would make a worthwhile difference, understand what it would involve and consider the cost before committing to anything.
You’re also free to leave the system as it is.
Is this something you’ll have to replace later?
The system delivered through a Day-1 Build is intended to become the live system for that job.
You aren’t buying a temporary prototype that must be thrown away once the business starts relying on it.
No one can sensibly promise that software will never need to change. Businesses develop, staff find better ways of handling work and requirements can move over time.
That’s different from knowing at the outset that the first system will need to be discarded.
If a later change becomes worthwhile, the starting point is something real:
- the records already exist
- the screens are already in use
- your team understands how the system works
- the business has evidence about what helps and what doesn’t
You’re improving a working system rather than beginning again with a blank page and a long list of assumptions.
Can the system change as your business changes?
Yes.
The system is built as readable, maintainable software. It can be changed if the business later needs different fields, stages, reports, access rules or ways of handling the work.
That doesn’t mean continual development is required.
A Day-1 Build may continue doing the same focused job without significant changes. If the system still handles that work properly, there’s no reason to add features simply because more could be built.
Any later work is a separate decision. It should have a clear purpose and a clear cost before you commit to it.
Does a Day-1 Build lead to another large software project?
It doesn’t have to.
The Day-1 Build may solve the specific problem that brought you to AlphaFirst. If that’s all the business needs, the system can continue doing that job.
The Day-1 Build doesn’t create a requirement for a second project.
You may later choose to add a report, connect another source of information or improve a related piece of work. Those are options, not unfinished parts of the original sale.
If a new requirement becomes too large or too different to treat as a small change, we should say so plainly. You can then decide whether it deserves further investment.
Are you locked in to AlphaFirst?
No. Changing hosting or using another provider doesn’t stop the system working.
It can be hosted by AlphaFirst or moved to a suitable server you control.
Your business data belongs to you. We can provide access to that data and agree how backups or an exit copy would be supplied.
There’s no recurring software licence fee that keeps the application switched on. Hosting is a separate monthly service. Ending AlphaFirst hosting doesn’t remove your right to continue using the system.
We’ve explained the wider choice between rented software and a system you control in Should your business rent software, or own the system it actually needs?
Your rights can also be set out in a written agreement covering:
- your continuing right to use the completed system
- a perpetual, non-exclusive licence to the shared AlphaFirst code included within it
- the rights applying to work developed specifically for your business
- access to readable application source code so another competent provider can maintain or develop the system
If you choose to move, AlphaFirst would charge for any work required to help with that move. This could include setting up another server, transferring data, testing the new installation, producing additional documentation or briefing another provider.
You’d be paying for the work involved, not for permission to leave.
We want customers to continue using AlphaFirst because the relationship continues to help their business, not because the system has been made difficult to move.
What if the Day-1 Build solves everything you needed?
Then it’s done its job.
You don’t need to add more features, replace another process or begin a wider software project.
The point of the Day-1 Build is to take one important piece of work and give it a proper place to live.
Once the system is in use, you can judge it by practical questions:
- Can staff see the information they need?
- Can they update the work without relying on side notes or memory?
- Is it easier to understand what is happening?
- Are records less likely to be missed or duplicated?
- Does the person responsible spend less time holding the process together by hand?
If the answer is yes, there may be nothing else that needs doing.
Where you stand after day one
At the end of a successful Day-1 Build, you should have:
- a live system for the agreed job
- a clear place for new work to be handled
- important starting data in place where practical
- a 30-day settling-in period for anything that doesn’t work as agreed and reasonable small adjustments
- the option to request changes later without being committed to them
- the freedom to host the system elsewhere or use another provider
- no hidden requirement to begin another project
The next step is to use the system and see whether the job that was taking too much time, effort or attention is now easier to manage.
You can also see examples of systems we’ve built for other businesses.
If one part of your business needs a clearer system around it, book a Day-1 Build call and we’ll tell you whether it fits a focused build or needs a different route.