Diagnose
Interviews, workflow review, and data before recommendations. We need to understand the real operation, not just the symptoms.
ProcessDeep in up front.
Deep in up front.
Clean on the way out.
The build process is designed to reduce surprises, keep decisions visible, and leave the client with a system they can actually own.
Delivery flow
Four phases, one visible build loop.
The point is not just to ship. The point is to understand the operation well enough that what gets shipped actually improves it.
Design
A plain-language plan with scope, systems, timeline, and success criteria before the build starts.
Build
Weekly demos, transparent decisions, and a tight feedback loop while change is still cheap.
Operate
Launch support, training, tuning, and a clean handoff once the system is stable in the real world.
Working rhythm
What it feels like to work together.
A good process should feel calm, legible, and steady. These are the habits that keep projects from drifting.
Weekly demos
You see the system evolve in real time instead of discovering the shape of it at the end.
Decision notes
Key tradeoffs, architecture calls, and scope decisions are kept visible and understandable.
Launch support
Before launch, we agree the support period, included fixes, contact route, and how additional work will be quoted.
Principles
The rules underneath the process.
These are the operating principles that keep the work strategic instead of just technically busy.
Build around reality
We design against how your business actually runs today, not how a software demo says it should run.
Keep systems legible
If only the person who built it can explain it, it is not finished. We optimize for clarity, ownership, and maintainability.
Measure what changed
Agree what success looks like before building, record a baseline where possible, and review what changed without overstating the evidence.
A clear first project, without the guesswork.
You do not need a polished brief. These are the details we work through before a build begins.
Who is this for?
Digital Refraction works with growing teams whose tools and handoffs no longer fit the work. LocalCare is the same business, with a smaller scope for owners without an operations team.
Who will I work with?
Your proposal will name the person responsible for delivery and your day-to-day contact. We agree who needs to review decisions before work starts.
Can you improve what we already have?
Yes. Start with the existing website, spreadsheet, or app. A configuration change or an off-the-shelf tool may be enough; custom software is useful when the missing workflow justifies it.
What does a small first project include?
One defined problem, agreed deliverables, review points, and a handoff. The proposal separates included work from additions such as more pages, integrations, data cleanup, or ongoing content changes.
What determines the fee and timeline?
The size of the workflow, number of pages or integrations, condition of the data, content readiness, and review time. We agree the price and schedule for the specific scope before starting; a small fix and a full website are different projects.
What costs extra?
Hosting, domains, paid tools, email services, and AI usage can have recurring charges. The proposal identifies which are needed, who pays for them, and whether support or future changes are separate.
What about ownership and leaving later?
Before starting, we document account ownership, access, the rights to content and custom code, third-party licences, and available data exports. The handoff should make clear what you can keep, move, or maintain elsewhere.
What happens after launch?
The agreed support plan sets out its duration, included fixes, contact method, response hours, and how extra work is priced. Launch support is not an unlimited maintenance subscription.
What will you need from us?
A person who can make decisions, examples of the current work, approved content, and access through an appropriate account invitation. We agree review dates and dependencies before setting the launch date.
Ready when you are
If the bottleneck is real, we can map it and build through it.
Tell us where work gets stuck. We will help identify a practical first step and what it would take to build it.