Understand it first. Build it in visible pieces. Keep it working.
Three engagements, meant to be taken in order. Each one ends with something you can use on its own — a plan, a working application, or a system that stays current.
Discovery & Architecture Sprint
A short, fixed‑fee engagement that answers one question honestly: what is actually wrong with this process, and what is the smallest thing that fixes it?
Together we walk the process as it really runs — including the workarounds. Data sources get inspected, integrations get tested for feasibility, and the people who do the work get asked what breaks. The output is a plan specific enough to price and build against.
You own the deliverables whether or not you build with hij2. If the right answer turns out to be a process change or an off‑the‑shelf tool, that's what the report says.
What you receive
- Current‑state process map — steps, owners, handoffs, systems, and where time and errors accumulate.
- Requirements written as what the business needs to do, with the rules your team already applies made explicit.
- Data and integration assessment — what exists, what's clean, what has to be reconciled, and what each connection realistically costs.
- Recommended approach, with the alternatives considered and the tradeoff in cost, speed, risk, and future flexibility.
- Risks, assumptions, and dependencies stated plainly, including what would need to change on your side.
- Delivery plan and budget range — milestones, sequence, acceptance criteria, and an estimate for the build.
Best when requirements, data quality, integrations, or stakeholder agreement are still uncertain — which is most of the time.
Custom Application Build
The agreed solution, built in milestones that each put something usable in your team's hands. Nothing waits for a single launch date at the end.
Every milestone has acceptance criteria written in operational terms — "a coordinator can close out a job without opening the spreadsheet" — so "done" isn't a matter of opinion. You see a working demo at the end of each one, and priorities can be resequenced between them.
Scope, exclusions, and assumptions are written down before work starts, and changes to them are discussed as tradeoffs rather than absorbed silently.
How a build runs
-
Milestone plan
The delivery plan from discovery becomes a sequence of milestones, ordered so the highest‑pain step is relieved first.
-
Build and demo
Each milestone ends in a live demo against its acceptance criteria, with the people who'll use it in the room.
-
Real‑data pilot
A small group runs the new workflow alongside the old one on real data, so gaps surface before anyone depends on it.
-
Cutover and handover
Data migrated, users trained, documentation delivered, and everything running in accounts you own.
Ongoing Engineering Partner
Internal software isn't finished when it ships. Prices change, a customer wants a different report, a new system needs connecting, someone finds a bug on a Friday afternoon.
A flat monthly retainer covers support, fixes, dependency and security updates, monitoring, and a defined block of improvement work each month — prioritised by you. It keeps the application from drifting back toward a spreadsheet workaround.
Month‑to‑month after an initial term, and available whether or not hij2 built the original system — subject to a short review of what's there.
Typically included
- Support with an agreed response window for issues that stop work.
- Bug fixes and small changes — new fields, adjusted rules, extra reports.
- Maintenance — dependency updates, security patches, backups verified.
- Monitoring, so failures are found before someone reports them.
- A monthly block of improvement time, spent on whatever you rank highest.
- A short monthly note covering what changed, what's coming, and anything worth deciding.
Exact response windows and the size of the monthly block are set in your agreement, based on how critical the system is.
What hij2 doesn't do
A short list, because knowing the boundaries early saves everyone a call.
- Fixed‑price builds before discovery. Quoting a build without knowing the data and integrations produces either a padded price or a project that goes wrong halfway through.
- Rewrites as an opening move. Replacing a working system is proposed only when keeping it demonstrably costs more.
- Staff augmentation. Engagements are scoped around an outcome, not an allocation of hours to someone else's backlog.
- Consumer apps, marketing sites, or games. The focus is internal business applications.
- Everything at once. As a solo practice, hij2 takes a small number of clients concurrently. If timing doesn't work, you'll be told at the first conversation.
Not sure which one you need?
Describe the process. If a discovery sprint isn't warranted — because the fix is smaller than that — you'll hear so before you're asked to pay for anything.