Software shaped by my work in architecture.
I build Monument in Melbourne around staged projects, staffing needs and mixed fees.
Why Monument exists
Early in my career, the architecture practice where I worked recorded time but still found out too late when a project had gone over. The timesheet held the hours. It did not hold the stages, fees and staffing plan needed to act on them.
Every practice I spoke to ran its projects differently, so Monument had to be customisable to fit each one's needs. I built Monument around how the work is broken down, from stages to individual tasks, with consultant scopes in between. The fee and staffing plan sit beside that structure.
Monument is just me for now. I build it, support it and talk to every practice that uses it. Their stages, fee terms and staffing decisions shape what I build next.
What drives Monument
Built from practice work
The first version grew from problems I saw inside an architecture practice. Project, fee and staffing decisions still shape what I build.
Stages stay connected
Put stages, consultant scopes and fee terms on one project. Don't know who'll do the work yet? Plan the hours against a role. Bring one project to the demo.
Warnings before the post-mortem
Review the hours still needed and the fee remaining before committing the team to the next stage.
Change the work once.
Scheduling, staffing and invoicing share one project structure. When the work changes, each view follows.
Test Monument on stages, scopes and fees.
I will model it with you and give you a straight answer on fit.