
We Run Our Business on Referrals
Fresh Projects is a UK-based software platform designed for architects, engineers, and other built-environment professionals to manage financial aspects of their projects. It helps teams track fees, timesheets, expenses, billing, and overall profitability to keep projects on budget and profitable. The platform also centralises project data, streamlines administrative tasks, and offers mobile app support for easy access and updates.
1a Colinette Road
London
SW15 6QG
© 2026 Fresh Projects
Product

We Run Our Business on Referrals
Fresh Projects is a UK-based software platform designed for architects, engineers, and other built-environment professionals to manage financial aspects of their projects. It helps teams track fees, timesheets, expenses, billing, and overall profitability to keep projects on budget and profitable. The platform also centralises project data, streamlines administrative tasks, and offers mobile app support for easy access and updates.
1a Colinette Road
London
SW15 6QG
© 2026 Fresh Projects
Product
The Software Works. So Why Won’t Everyone Use It?
The Software Works. So Why Won’t Everyone Use It?
The Software Works. So Why Won’t Everyone Use It?
Reading Time:
Reading Time:
10
10
minute(s)
minute(s)


Changing practice management software sounds straightforward when it is written into an implementation plan.
Configure the system > Move the data > Train the team > Go live.
The reality inside a busy architecture or engineering practice is rather different. Projects don't stop when a new system is introduced. Deadlines still need to be met, clients still need answers, timesheets still need completing, and invoices still need raising. Project managers cannot simply set aside their existing workload while everyone learns a new way of working.
That pressure shows up in the research. Autodesk’s 2025 research into architecture, engineering, construction and operations found that 34% of respondents identified the time needed to invest in new tools and ways of working as a barrier to digital transformation. Another 30% pointed to a lack of knowledge or technical skills, while 26% cited resistance to changing established workflows. Cost ranked highest at 44%, but the findings make clear that buying the technology is only part of the challenge.
Architecture has a particularly interesting relationship with technology change. In RIBA’s 2025 AI research, 6% of respondents described their organisation as a leading digital innovator and 21% as an early adopter. At the other end of the scale, 23% considered their organisation a late adopter and 5% said they tended to resist digital innovation in favour of more traditional techniques.
This does not mean architects and engineers simply dislike new technology.
Quite often, the existing way of working has one enormous advantage: everybody already knows how to use it.
They know which spreadsheet to open, which report needs adjusting before the management meeting, which workaround gets around an awkward process and who to ask when something does not quite add up.
A replacement can be objectively more capable and still feel like the riskier option when the team has live projects to deliver.
That is the challenge this final part of The Adoption Advantage is designed to tackle.
From recognising the adoption gap to changing everyday behaviour
In Part 1 of this series, 7 Signs Your A&E Practice Management Software Isn’t Fully Adopted, we looked at the gap between implementing software and genuinely adopting it.
Licences, logins and completed timesheets can make implementation appear healthy while private spreadsheets, delayed forecasts and manual reporting processes continue underneath. The important question was not simply whether people had access to the system, but whether they could find the information they needed, understand it, trust it and use it to make better decisions.
Part 2, Five Ways to Build Commercial Confidence Across Your Project Teams, moved the conversation beyond Finance. Better commercial information only becomes useful when project managers and other people responsible for delivery can understand what it means for the work they manage.
There is one final problem to solve:
You can configure the right system, provide the right information and explain the commercial value perfectly, but people still have to change what they do every day.
That is where adoption succeeds or stalls.
Why familiar software can be surprisingly difficult to replace
There is a temptation to interpret continued use of an old system or spreadsheet as resistance. Sometimes it is. Often, however, the behaviour is quite rational.
If somebody can produce the information they need in ten minutes using a process they have followed for five years, asking them to abandon it for a process they do not yet understand introduces uncertainty.
Will it take longer?
Will the data be right?
Can they fix something themselves if it goes wrong?
Will they still meet Friday's deadline?
Does the change actually make their job easier, or has somebody elsewhere in the business simply decided that they should use a different system?
Research into organisational change supports the importance of these questions. Prosci identifies lack of awareness about the reason for a change as the most common cause of employee resistance in its research. Other common causes include changes to job roles, fear of the unknown, lack of trust or support from leaders, and exclusion from decisions about the change.
That matters because an adoption problem cannot always be solved with more training.
Sometimes the workflow itself needs attention.
The spreadsheet someone refuses to give up may be telling you something useful about the information they need, the way they work or a gap in the new process.
The aim should therefore be to understand the workaround before trying to remove it.
A 30-day plan for better practice management software adoption
Thirty days will not transform every behaviour across a practice.
It is, however, long enough to identify where adoption is getting stuck, remove some of the friction and start making the new system part of normal working routines.
The plan below is deliberately practical. It is designed to fit around live project work rather than becoming another internal transformation programme that employees have to find time for.
Days 1–7: Find the friction

Start with the work people are actually doing rather than the functionality the software technically provides.
Look for places where information leaves the system.
Are project managers still maintaining their own fee spreadsheets?
Does Finance export information before it can be trusted?
Are resource conversations happening in a separate document?
Are people entering the same information more than once?
Does one person have a monthly reporting process nobody else fully understands?
These are not simply signs of disobedience; they are clues.
Speak to the people doing the work and ask what makes the alternative easier.
You might discover that they cannot find the information they need quickly enough. The report may not answer the question they are trying to answer. They may not understand where the number came from. Or the existing process may simply be quicker.
Part 1 of this series made the same point about spreadsheets: project managers often keep them because they cannot find the required information, do not trust the system data, find a workflow too slow or need analysis that the main platform does not provide. The reason for the workaround matters more than the existence of the spreadsheet itself.
At the end of the first week, you should be able to identify a handful of specific friction points rather than declaring that “the team isn't using the system properly”.
That is a much more useful problem to solve.
Questions to ask
Which tasks still happen outside the system?
What information do people regularly ask somebody else to provide?
Where is information being entered twice?
Which workflows regularly need a workaround?
What makes the current workaround attractive?
Days 8–14: Make one everyday task noticeably easier

One of the fastest ways to lose adoption is to sell people a long list of future benefits while making something they do every day more difficult.
Choose one or two repeated workflows and concentrate on making those work well.
For an architecture or engineering practice, that might be:
recording time
checking the current position of a project
reviewing workload
raising an invoice
updating a forecast
producing a familiar management report
The question is simple:
When does this make somebody's working day easier?
Take timesheets as an example.
Timesheet completion matters because the information feeds project costs, utilisation and profitability. But none of that matters if capturing time is cumbersome enough that employees avoid doing it until Friday afternoon or need to be chased every week.
The business value and the user experience are connected.
A useful demonstration therefore does not need to explain every timesheet feature. Show somebody how quickly they can find the work they are doing, capture their time and move on.
The same principle applies elsewhere.
If a leadership team already relies on a particular Excel report, adoption may improve by connecting that familiar reporting environment to current practice data rather than insisting that the report itself must disappear.
Change becomes easier when employees can see what improves without having to relearn everything at once.
Days 15–21: Put the system into the routines that already run the practice

Software becomes part of the business when the business begins using it to run.
That sounds obvious, but it is easy to launch a new platform while continuing to run the important conversations from old reports and private spreadsheets.
If the weekly project meeting is still driven from a separate spreadsheet, that spreadsheet remains the operational system that matters to the people in the room.
If the resource meeting relies on somebody manually assembling availability beforehand, employees have little reason to trust the new resource-planning view.
If senior leaders ask Finance for a separate report every month rather than looking at the information in the platform, the organisation is reinforcing the old behaviour.
Use the new system in the routines that already exist.
That might mean bringing current project performance into project reviews, using live workload information in resource conversations or reviewing the same commercial information with project managers and Finance.
Do not add another meeting called “software adoption”.
Make the software useful in the meetings people already attend.
This is also where leadership behaviour matters. McKinsey's research into organisational transformations found that companies where senior managers communicated openly about progress were substantially more likely to report successful transformation, while employee ownership was also strongly associated with better outcomes. The research is broader than software implementation specifically, but the principle is relevant: sustained change is much harder when leadership treats it as something everybody else needs to do.
Days 22–30: Measure whether the work changed

By this point, avoid falling back on the easiest adoption metrics.
A login proves somebody logged in.
A licence proves you bought a licence.
A submitted timesheet proves somebody submitted a timesheet.
Those numbers have a place, but they do not tell you whether the system has become useful.
Return to the friction you identified in week one.
Has the private spreadsheet disappeared?
Are fewer people asking Finance to interpret their project position?
Can another person run the report if its usual owner is away?
Is workload information current enough to use in the resourcing meeting?
Are people entering information once rather than copying it between systems?
Can project managers answer more questions without waiting for somebody else to produce the data?
Those are much stronger adoption signals because they measure changes in behaviour and decision-making.
They also tell you where the next problem sits.
If everybody completes timesheets but project managers still maintain separate profitability spreadsheets, time capture is not your current adoption problem.
If project managers use the system but senior leadership still asks Finance to rebuild every management report in Excel, the friction sits somewhere else.
Good adoption measurement helps you find that difference.
Prosci's research also suggests that sustaining change deserves deliberate attention. Among research participants who planned reinforcement or sustainment activities, 81% met or exceeded their objectives.
Adoption is therefore not finished on go-live day, or even on day 30.
The aim of the first month is to create enough useful behaviour that the new way of working starts to reinforce itself.
What should change after 30 days?
You should not expect every workaround to have vanished.
You should expect to understand them better.
After 30 days, a practice should have a clearer picture of:
where people still leave the system
why those workarounds exist
which workflows have become easier
where information is trusted
where confidence is still low
which everyday routines can reinforce better use
what the next adoption priority should be
That creates a much more useful improvement cycle than repeatedly reminding people to use the software.
Good adoption does not require people to love software
Most architects and engineers did not choose their careers because they wanted to spend more time thinking about practice management systems.
They want to design, create, engineer, solve problems, deliver projects and serve clients.
The job of practice management software is to support that work without demanding unnecessary attention of its own.
At Fresh Projects, that principle shapes how we think about adoption. Everyday activities such as time capture, project management, resourcing, invoicing and reporting need to fit naturally into the way a practice works because the commercial picture is only as useful as the information being captured underneath it.
Implementation can make software available.
Training can show people what to do.
The harder and more valuable task is making the new way of working useful enough that people stop needing the old workaround.
That is when implementation starts becoming adoption.
The Adoption Advantage: your 30-day checklist
Days 1–7: Find the friction
Identify work still happening outside the system
Speak to the people using workarounds
Find duplicated data entry
Understand why existing processes remain attractive
Choose the highest-impact friction points
Days 8–14: Make everyday work easier
Select one or two repeated workflows
Show the benefit in the context of the employee's actual job
Remove unnecessary steps
Preserve useful familiar processes where appropriate
Check whether the new workflow is genuinely quicker or clearer
Days 15–21: Build it into existing routines
Use current system information in project reviews
Use it in resource conversations
Use it in management and commercial meetings
Make leaders visible users of the information
Stop reinforcing parallel processes unnecessarily
Days 22–30: Measure useful behaviour
Check whether workarounds are reducing
Test whether information can be found without specialist help
Look for duplicated processes that remain
Measure whether information is current when decisions are made
Identify the next source of adoption friction
Continue the series
Read Part 1: 7 Signs Your A&E Practice Management Software Isn’t Fully Adopted
Read Part 2: Five Ways to Build Commercial Confidence Across Your Project Teams
Or explore how Fresh Projects helps architecture and engineering practices bring project, commercial and resource information together in one place.

Changing practice management software sounds straightforward when it is written into an implementation plan.
Configure the system > Move the data > Train the team > Go live.
The reality inside a busy architecture or engineering practice is rather different. Projects don't stop when a new system is introduced. Deadlines still need to be met, clients still need answers, timesheets still need completing, and invoices still need raising. Project managers cannot simply set aside their existing workload while everyone learns a new way of working.
That pressure shows up in the research. Autodesk’s 2025 research into architecture, engineering, construction and operations found that 34% of respondents identified the time needed to invest in new tools and ways of working as a barrier to digital transformation. Another 30% pointed to a lack of knowledge or technical skills, while 26% cited resistance to changing established workflows. Cost ranked highest at 44%, but the findings make clear that buying the technology is only part of the challenge.
Architecture has a particularly interesting relationship with technology change. In RIBA’s 2025 AI research, 6% of respondents described their organisation as a leading digital innovator and 21% as an early adopter. At the other end of the scale, 23% considered their organisation a late adopter and 5% said they tended to resist digital innovation in favour of more traditional techniques.
This does not mean architects and engineers simply dislike new technology.
Quite often, the existing way of working has one enormous advantage: everybody already knows how to use it.
They know which spreadsheet to open, which report needs adjusting before the management meeting, which workaround gets around an awkward process and who to ask when something does not quite add up.
A replacement can be objectively more capable and still feel like the riskier option when the team has live projects to deliver.
That is the challenge this final part of The Adoption Advantage is designed to tackle.
From recognising the adoption gap to changing everyday behaviour
In Part 1 of this series, 7 Signs Your A&E Practice Management Software Isn’t Fully Adopted, we looked at the gap between implementing software and genuinely adopting it.
Licences, logins and completed timesheets can make implementation appear healthy while private spreadsheets, delayed forecasts and manual reporting processes continue underneath. The important question was not simply whether people had access to the system, but whether they could find the information they needed, understand it, trust it and use it to make better decisions.
Part 2, Five Ways to Build Commercial Confidence Across Your Project Teams, moved the conversation beyond Finance. Better commercial information only becomes useful when project managers and other people responsible for delivery can understand what it means for the work they manage.
There is one final problem to solve:
You can configure the right system, provide the right information and explain the commercial value perfectly, but people still have to change what they do every day.
That is where adoption succeeds or stalls.
Why familiar software can be surprisingly difficult to replace
There is a temptation to interpret continued use of an old system or spreadsheet as resistance. Sometimes it is. Often, however, the behaviour is quite rational.
If somebody can produce the information they need in ten minutes using a process they have followed for five years, asking them to abandon it for a process they do not yet understand introduces uncertainty.
Will it take longer?
Will the data be right?
Can they fix something themselves if it goes wrong?
Will they still meet Friday's deadline?
Does the change actually make their job easier, or has somebody elsewhere in the business simply decided that they should use a different system?
Research into organisational change supports the importance of these questions. Prosci identifies lack of awareness about the reason for a change as the most common cause of employee resistance in its research. Other common causes include changes to job roles, fear of the unknown, lack of trust or support from leaders, and exclusion from decisions about the change.
That matters because an adoption problem cannot always be solved with more training.
Sometimes the workflow itself needs attention.
The spreadsheet someone refuses to give up may be telling you something useful about the information they need, the way they work or a gap in the new process.
The aim should therefore be to understand the workaround before trying to remove it.
A 30-day plan for better practice management software adoption
Thirty days will not transform every behaviour across a practice.
It is, however, long enough to identify where adoption is getting stuck, remove some of the friction and start making the new system part of normal working routines.
The plan below is deliberately practical. It is designed to fit around live project work rather than becoming another internal transformation programme that employees have to find time for.
Days 1–7: Find the friction

Start with the work people are actually doing rather than the functionality the software technically provides.
Look for places where information leaves the system.
Are project managers still maintaining their own fee spreadsheets?
Does Finance export information before it can be trusted?
Are resource conversations happening in a separate document?
Are people entering the same information more than once?
Does one person have a monthly reporting process nobody else fully understands?
These are not simply signs of disobedience; they are clues.
Speak to the people doing the work and ask what makes the alternative easier.
You might discover that they cannot find the information they need quickly enough. The report may not answer the question they are trying to answer. They may not understand where the number came from. Or the existing process may simply be quicker.
Part 1 of this series made the same point about spreadsheets: project managers often keep them because they cannot find the required information, do not trust the system data, find a workflow too slow or need analysis that the main platform does not provide. The reason for the workaround matters more than the existence of the spreadsheet itself.
At the end of the first week, you should be able to identify a handful of specific friction points rather than declaring that “the team isn't using the system properly”.
That is a much more useful problem to solve.
Questions to ask
Which tasks still happen outside the system?
What information do people regularly ask somebody else to provide?
Where is information being entered twice?
Which workflows regularly need a workaround?
What makes the current workaround attractive?
Days 8–14: Make one everyday task noticeably easier

One of the fastest ways to lose adoption is to sell people a long list of future benefits while making something they do every day more difficult.
Choose one or two repeated workflows and concentrate on making those work well.
For an architecture or engineering practice, that might be:
recording time
checking the current position of a project
reviewing workload
raising an invoice
updating a forecast
producing a familiar management report
The question is simple:
When does this make somebody's working day easier?
Take timesheets as an example.
Timesheet completion matters because the information feeds project costs, utilisation and profitability. But none of that matters if capturing time is cumbersome enough that employees avoid doing it until Friday afternoon or need to be chased every week.
The business value and the user experience are connected.
A useful demonstration therefore does not need to explain every timesheet feature. Show somebody how quickly they can find the work they are doing, capture their time and move on.
The same principle applies elsewhere.
If a leadership team already relies on a particular Excel report, adoption may improve by connecting that familiar reporting environment to current practice data rather than insisting that the report itself must disappear.
Change becomes easier when employees can see what improves without having to relearn everything at once.
Days 15–21: Put the system into the routines that already run the practice

Software becomes part of the business when the business begins using it to run.
That sounds obvious, but it is easy to launch a new platform while continuing to run the important conversations from old reports and private spreadsheets.
If the weekly project meeting is still driven from a separate spreadsheet, that spreadsheet remains the operational system that matters to the people in the room.
If the resource meeting relies on somebody manually assembling availability beforehand, employees have little reason to trust the new resource-planning view.
If senior leaders ask Finance for a separate report every month rather than looking at the information in the platform, the organisation is reinforcing the old behaviour.
Use the new system in the routines that already exist.
That might mean bringing current project performance into project reviews, using live workload information in resource conversations or reviewing the same commercial information with project managers and Finance.
Do not add another meeting called “software adoption”.
Make the software useful in the meetings people already attend.
This is also where leadership behaviour matters. McKinsey's research into organisational transformations found that companies where senior managers communicated openly about progress were substantially more likely to report successful transformation, while employee ownership was also strongly associated with better outcomes. The research is broader than software implementation specifically, but the principle is relevant: sustained change is much harder when leadership treats it as something everybody else needs to do.
Days 22–30: Measure whether the work changed

By this point, avoid falling back on the easiest adoption metrics.
A login proves somebody logged in.
A licence proves you bought a licence.
A submitted timesheet proves somebody submitted a timesheet.
Those numbers have a place, but they do not tell you whether the system has become useful.
Return to the friction you identified in week one.
Has the private spreadsheet disappeared?
Are fewer people asking Finance to interpret their project position?
Can another person run the report if its usual owner is away?
Is workload information current enough to use in the resourcing meeting?
Are people entering information once rather than copying it between systems?
Can project managers answer more questions without waiting for somebody else to produce the data?
Those are much stronger adoption signals because they measure changes in behaviour and decision-making.
They also tell you where the next problem sits.
If everybody completes timesheets but project managers still maintain separate profitability spreadsheets, time capture is not your current adoption problem.
If project managers use the system but senior leadership still asks Finance to rebuild every management report in Excel, the friction sits somewhere else.
Good adoption measurement helps you find that difference.
Prosci's research also suggests that sustaining change deserves deliberate attention. Among research participants who planned reinforcement or sustainment activities, 81% met or exceeded their objectives.
Adoption is therefore not finished on go-live day, or even on day 30.
The aim of the first month is to create enough useful behaviour that the new way of working starts to reinforce itself.
What should change after 30 days?
You should not expect every workaround to have vanished.
You should expect to understand them better.
After 30 days, a practice should have a clearer picture of:
where people still leave the system
why those workarounds exist
which workflows have become easier
where information is trusted
where confidence is still low
which everyday routines can reinforce better use
what the next adoption priority should be
That creates a much more useful improvement cycle than repeatedly reminding people to use the software.
Good adoption does not require people to love software
Most architects and engineers did not choose their careers because they wanted to spend more time thinking about practice management systems.
They want to design, create, engineer, solve problems, deliver projects and serve clients.
The job of practice management software is to support that work without demanding unnecessary attention of its own.
At Fresh Projects, that principle shapes how we think about adoption. Everyday activities such as time capture, project management, resourcing, invoicing and reporting need to fit naturally into the way a practice works because the commercial picture is only as useful as the information being captured underneath it.
Implementation can make software available.
Training can show people what to do.
The harder and more valuable task is making the new way of working useful enough that people stop needing the old workaround.
That is when implementation starts becoming adoption.
The Adoption Advantage: your 30-day checklist
Days 1–7: Find the friction
Identify work still happening outside the system
Speak to the people using workarounds
Find duplicated data entry
Understand why existing processes remain attractive
Choose the highest-impact friction points
Days 8–14: Make everyday work easier
Select one or two repeated workflows
Show the benefit in the context of the employee's actual job
Remove unnecessary steps
Preserve useful familiar processes where appropriate
Check whether the new workflow is genuinely quicker or clearer
Days 15–21: Build it into existing routines
Use current system information in project reviews
Use it in resource conversations
Use it in management and commercial meetings
Make leaders visible users of the information
Stop reinforcing parallel processes unnecessarily
Days 22–30: Measure useful behaviour
Check whether workarounds are reducing
Test whether information can be found without specialist help
Look for duplicated processes that remain
Measure whether information is current when decisions are made
Identify the next source of adoption friction
Continue the series
Read Part 1: 7 Signs Your A&E Practice Management Software Isn’t Fully Adopted
Read Part 2: Five Ways to Build Commercial Confidence Across Your Project Teams
Or explore how Fresh Projects helps architecture and engineering practices bring project, commercial and resource information together in one place.
Published:
Published:


The Software Works. So Why Won’t Everyone Use It?
The Software Works. So Why Won’t Everyone Use It?
The Software Works. So Why Won’t Everyone Use It?
A practical 30-day adoption plan for architecture and engineering firms
A practical 30-day adoption plan for architecture and engineering firms


What does the Autumn Budget 2026 mean for architecture and engineering firms?
What does the Autumn Budget 2026 mean for architecture and engineering firms?
What does the Autumn Budget 2026 mean for architecture and engineering firms?
What the Autumn Budget 2026 means for UK architecture, engineering and QS firms, from social housing and regional investment to project appraisal and procurement.
What the Autumn Budget 2026 means for UK architecture, engineering and QS firms, from social housing and regional investment to project appraisal and procurement.


Practice Performance Management & Project Information Management: Why Growing AEC Firms Need Both
Practice Performance Management & Project Information Management: Why Growing AEC Firms Need Both
Practice Performance Management & Project Information Management: Why Growing AEC Firms Need Both
Growing architecture and engineering firms need two kinds of visibility: how the practice is performing, and what the project knows. This piece explores why both matter as teams, projects and complexity grow.
Growing architecture and engineering firms need two kinds of visibility: how the practice is performing, and what the project knows. This piece explores why both matter as teams, projects and complexity grow.


Five ways to build commercial confidence across your project teams
Five ways to build commercial confidence across your project teams
Five ways to build commercial confidence across your project teams
How architecture, engineering, quantity surveying and other built-environment firms can help project teams understand fees, time and performance without turning everyone into finance specialists.
How architecture, engineering, quantity surveying and other built-environment firms can help project teams understand fees, time and performance without turning everyone into finance specialists.


Can your project record stand up when it matters? 5 practical tests for AEC firms.
Can your project record stand up when it matters? 5 practical tests for AEC firms.
Can your project record stand up when it matters? 5 practical tests for AEC firms.
Five simple tests to uncover gaps in your project information before they become commercial, compliance or delivery risks.
Five simple tests to uncover gaps in your project information before they become commercial, compliance or delivery risks.


7 Signs Your A&E Practice Management Software Isn’t Fully Adopted
7 Signs Your A&E Practice Management Software Isn’t Fully Adopted
7 Signs Your A&E Practice Management Software Isn’t Fully Adopted
How growing A&E firms can close the gap between software implementation and whole-team commercial value
How growing A&E firms can close the gap between software implementation and whole-team commercial value


When Teams Stop Speaking The Same Operational Language
When Teams Stop Speaking The Same Operational Language
When Teams Stop Speaking The Same Operational Language
Why growing architecture practices often lose reporting confidence gradually, long before anyone formally identifies a systems problem.
Why growing architecture practices often lose reporting confidence gradually, long before anyone formally identifies a systems problem.


What It Really Means When a Client Recommends You
What It Really Means When a Client Recommends You
What It Really Means When a Client Recommends You
Why the built environment has always grown through trust, and what that means for the firms that do it well.
Why the built environment has always grown through trust, and what that means for the firms that do it well.


Why Reporting Leaves Firms Guessing
Why Reporting Leaves Firms Guessing
Why Reporting Leaves Firms Guessing
Inside many built environment firms, meetings meant for decisions quietly turn into debates about the numbers on the page.
Inside many built environment firms, meetings meant for decisions quietly turn into debates about the numbers on the page.


Why Multi-Office Firms Lack Visibility
Why Multi-Office Firms Lack Visibility
Why Multi-Office Firms Lack Visibility
In many built environment consultancies, reporting technically works. The challenge is that clarity often arrives after the moment when it would have influenced action.
In many built environment consultancies, reporting technically works. The challenge is that clarity often arrives after the moment when it would have influenced action.


Why Reporting Slows Firms Down
Why Reporting Slows Firms Down
Why Reporting Slows Firms Down
Even with reporting systems in place, many architecture, engineering and quantity surveying firms find that insight arrives too late to influence decisions during delivery.
Even with reporting systems in place, many architecture, engineering and quantity surveying firms find that insight arrives too late to influence decisions during delivery.


Compare A&E Management Tools
Compare A&E Management Tools
Compare A&E Management Tools
Choosing a practice management system is no longer about feature lists. This guide explains how architecture and engineering firms should compare tools in 2026, focusing on adoption, usability and decision-making rather than complexity.
Choosing a practice management system is no longer about feature lists. This guide explains how architecture and engineering firms should compare tools in 2026, focusing on adoption, usability and decision-making rather than complexity.


Spreadsheets in A&E Firms: What Works
Spreadsheets in A&E Firms: What Works
Spreadsheets in A&E Firms: What Works
A practical guide to using Excel and Sheets well, and knowing when to graduate to purpose-built systems without losing the flexibility you love.
A practical guide to using Excel and Sheets well, and knowing when to graduate to purpose-built systems without losing the flexibility you love.


Women in AEC at Fresh Projects
Women in AEC at Fresh Projects
Women in AEC at Fresh Projects
Why representation, visibility and better systems matter for the future of architecture and engineering
Why representation, visibility and better systems matter for the future of architecture and engineering


Architecture Leadership Challenges
Architecture Leadership Challenges
Architecture Leadership Challenges
How firm leaders can protect margin, prepare successors and modernise delivery without losing what made them successful
How firm leaders can protect margin, prepare successors and modernise delivery without losing what made them successful


5 Ways to Outgrow Spreadsheets Profitably
5 Ways to Outgrow Spreadsheets Profitably
5 Ways to Outgrow Spreadsheets Profitably
How architecture and engineering practices protect margin as teams and project complexity increase
How architecture and engineering practices protect margin as teams and project complexity increase


The Profitability Pyramid Explained
The Profitability Pyramid Explained
The Profitability Pyramid Explained
Understanding the real drivers of financial performance for medium and large practices over the past year
Understanding the real drivers of financial performance for medium and large practices over the past year


3 Lessons to Help You Run a More Profitable Practice
3 Lessons to Help You Run a More Profitable Practice
3 Lessons to Help You Run a More Profitable Practice
Practical insights from A&E leaders on spotting profit risks early, communicating value, and protecting margins
Practical insights from A&E leaders on spotting profit risks early, communicating value, and protecting margins


Embracing Neurodiversity in Architecture
Embracing Neurodiversity in Architecture
Embracing Neurodiversity in Architecture
How inclusive practice design can unlock creativity, innovation and operational clarity
How inclusive practice design can unlock creativity, innovation and operational clarity


Profitable Projects: Winning the Right Projects in AEC
Profitable Projects: Winning the Right Projects in AEC
Profitable Projects: Winning the Right Projects in AEC
How to qualify leads, focus your pipeline and forecast success more confidently
How to qualify leads, focus your pipeline and forecast success more confidently


Profitable Projects: The Art of Cashflow Alchemy in AEC
Profitable Projects: The Art of Cashflow Alchemy in AEC
Profitable Projects: The Art of Cashflow Alchemy in AEC
How architecture and engineering firms can turn unpredictable cash flow into a strategic advantage
How architecture and engineering firms can turn unpredictable cash flow into a strategic advantage


Setting Fees for Profitable Projects
Setting Fees for Profitable Projects
Setting Fees for Profitable Projects
Why bottom-up fee setting, clear scope and real-time cost visibility underpin profitable projects
Why bottom-up fee setting, clear scope and real-time cost visibility underpin profitable projects


Tools That Improve A&E Profitability
Tools That Improve A&E Profitability
Tools That Improve A&E Profitability
Why better visibility across projects, people and finances is now essential for sustainable practice performance
Why better visibility across projects, people and finances is now essential for sustainable practice performance


How to Manage Inflation on Architecture Projects
How to Manage Inflation on Architecture Projects
How to Manage Inflation on Architecture Projects
Practical ways to protect fees and margins when costs change mid-project
Practical ways to protect fees and margins when costs change mid-project


An Architect’s Guide to Project Budgeting
An Architect’s Guide to Project Budgeting
An Architect’s Guide to Project Budgeting
How to build realistic, profitable project budgets that support better pricing and delivery
How to build realistic, profitable project budgets that support better pricing and delivery


Improve Project Profitability: An Architect’s Guide
Improve Project Profitability: An Architect’s Guide
Improve Project Profitability: An Architect’s Guide
Practical ways architecture practices can protect margins and make better commercial decisions
Practical ways architecture practices can protect margins and make better commercial decisions


Calculate Your Cost Rate in 3 Simple Steps
Calculate Your Cost Rate in 3 Simple Steps
Calculate Your Cost Rate in 3 Simple Steps
Why understanding your true cost rate is the foundation of profitable fees, resourcing and decision-making
Why understanding your true cost rate is the foundation of profitable fees, resourcing and decision-making


When to Hire: Key Decisions
When to Hire: Key Decisions
When to Hire: Key Decisions
Why workload visibility and forecasting matter more than instinct in mid-sized architecture practices
Why workload visibility and forecasting matter more than instinct in mid-sized architecture practices


5 Basics to Improve Profitability
5 Basics to Improve Profitability
5 Basics to Improve Profitability
Five practical habits that help architecture practices improve profitability without adding complexity
Five practical habits that help architecture practices improve profitability without adding complexity


3 Questions for Profitable Firms
3 Questions for Profitable Firms
3 Questions for Profitable Firms
How clear insight into projects, clients and utilisation drives better decisions in mid-sized A&E firms
How clear insight into projects, clients and utilisation drives better decisions in mid-sized A&E firms


What Makes Firms More Profitable?
What Makes Firms More Profitable?
What Makes Firms More Profitable?
Why the most profitable firms spend less time on financial management and still make better decisions
Why the most profitable firms spend less time on financial management and still make better decisions


A-Team Approach to Profitability
A-Team Approach to Profitability
A-Team Approach to Profitability
Why reallocating work across roles can dramatically improve utilisation and margins in 50–100 person A&E practices
Why reallocating work across roles can dramatically improve utilisation and margins in 50–100 person A&E practices


I Love Excel. I Hate Excel.
I Love Excel. I Hate Excel.
I Love Excel. I Hate Excel.
Why spreadsheets break down in 50–100 person architecture and engineering practices, and what works better
Why spreadsheets break down in 50–100 person architecture and engineering practices, and what works better


Getting Project Fees Right
Getting Project Fees Right
Getting Project Fees Right
How accurate budgeting and disciplined scope control protect profitability in 50–100 person A&E practices
How accurate budgeting and disciplined scope control protect profitability in 50–100 person A&E practices


Working Capital Risks in A&E Firms
Working Capital Risks in A&E Firms
Working Capital Risks in A&E Firms
The financial blind spot that catches even well-run architecture and engineering practices
The financial blind spot that catches even well-run architecture and engineering practices

We Run Our Business on Referrals
Fresh Projects is a UK-based software platform designed for architects, engineers, and other built-environment professionals to manage financial aspects of their projects. It helps teams track fees, timesheets, expenses, billing, and overall profitability to keep projects on budget and profitable. The platform also centralises project data, streamlines administrative tasks, and offers mobile app support for easy access and updates.
1a Colinette Road
London
SW15 6QG
© 2026 Fresh Projects







