How we work / 05
How your work actually gets done.
We first learn what is not working, who uses it, and which tools must stay. Then we divide the project into working pieces you can review.
We plan security before development and update the documentation while we build.
01Frame
Understand the current problem
We review the current tools, data, and workflow with the people who use them. We also record the failures or delays the project needs to fix.
Before development starts, we write down what the finished work must do and what is not included. If Furnus is the wrong team, we aim to identify that before the project begins.
We look at
- The work as it runs today
- Who uses it and who approves changes
- The data and the systems already in play
- Where it breaks or slows you down, and what that costs
- The security, policies, and regulation you operate under
You leave with
- A clear picture of the current state
- Scope in writing
- What the finished work must do
- A recommended place to start
02Design
Plan the build
The plan accounts for existing software, access rules, required approvals, and maintenance after launch.
We plan access, security, and maintenance before development, when changes are easier to make.
We design
- The architecture, and how it works with what you already run
- How people and work move through it
- Where data lives and what it is trusted for
- The integrations it depends on
- Who can see and do what
- How results get measured
- The security or policy boundaries, as needed
You approve
- The approach, before we build it
- The stages we will deliver in
- What each stage has to prove
- The technical calls that carry weight
03Build
Review working versions
The people who planned your work are the ones building it. We deliver in the agreed stages, and you can review each piece as it is completed. We record important decisions and update the documentation as your work changes.
You review your work before launch instead of seeing it for the first time at the end.
You see
- Working software, page designs, and current documentation
- Live reviews before the next part is built
- Why we chose an approach
- What is finished and what remains
We keep
- The architecture notes
- The technical documentation
- A record of configuration and access
- The reasoning behind each change
- The runbooks and work aids the project needs
04Prove
Test the finished work
We test the finished work against the requirements agreed at the start.
What we measure depends on your work: revenue traced back to its source, conversion, hours handed back to your team, errors gone, response times under real load, acceptance tests passed, or a process that now runs the same way every time.
We validate
- The acceptance criteria we agreed on
- That it behaves the way it should
- Performance and reliability under real load
- The access and security requirements
- The documentation and training you need
You receive
- Results you can see for yourself
- The test and validation evidence
- The final documentation
- The known limits, and what is still open
05Run
Decide who maintains it
Before development, we agree on what Furnus will maintain and what your team will maintain after launch.
Either way, the code, the accounts, and the documentation are yours, so you can bring your work in-house or move it elsewhere whenever you decide. You can change the arrangement later as responsibilities shift.
You run it
We hand over the agreed files, documentation, and access, then train your team to operate the finished work.
We run it
We keep it running. Hosting, monitoring, and changes. Live analytics are exposed to you, and in-person reporting and check-ins are completed on an agreed upon basis.
Shared
We split it. Your team owns the day-to-day and we hold the parts that need an engineer on hand; or another arrangement we agree to.
Ways to hire Furnus
Choose a project or ongoing agreement
The work may be contracted as one project, a related group of projects, or ongoing part-time support.
Project
A project has defined work, an agreed price, and either a handoff or support agreement at the end.
Good for
- A new site
- A custom tool
- An automation
- An integration
Program
When a website, campaign, and internal software depend on one another, we can plan and deliver them as one program.
Good for
- Modernization
- Multi-system work
- Web, growth, and measurement together
- Work that crosses several services
Fractional seat
A fractional agreement gives you part-time technical or marketing leadership.
Good for
- Ongoing technical ownership
- Stewardship of the systems you depend on
- Steady, managed improvement
- Cross-functional work with no clean project edge
What stays the same every time.
Named project lead
A named Furnus lead is assigned to your account. The person designing your work will usually perform or supervise the build.
Security-first design
Access and data boundaries are decided in the architecture, while they are still free to change.
Inspectable, accessible work
You can review working versions and the reasons behind material technical choices during the project.
Documentation kept current during the project
Documentation is updated as the build or design work is completed.
Proven technology first
We use established tools unless the project has a clear reason to do something different.
Ownership stays clear
The project agreement states which accounts, source files, access, and ongoing services are handed over or maintained by Furnus.
Start here
Describe what is failing or what you need built.
You do not need to choose a service first. Describe how your work operates today.
It starts with one conversation and a look at what you already have.