Most failed internal software projects were scoped before anyone understood the process.
The way hij2 works is built around avoiding that: understand the real workflow first, propose the smallest thing that fixes it, and deliver in pieces small enough that a wrong turn is cheap to correct.
Five commitments that shape every engagement
Your spreadsheet is a specification
A file that a team has maintained for years contains real business rules, edge cases, and exceptions that nobody ever wrote down. Discovery starts by reading it as documentation. Those rules carry forward — the file's fragility is what gets left behind.
The smallest useful solution wins
Before an application is proposed, the cheaper options get considered honestly: a process change, a single integration, a report, a better use of a tool you already pay for. A large build is recommended only when the small ones genuinely don't reach.
Value arrives early, not at the end
Milestones are sequenced so the most painful step is relieved first. If an engagement ended after milestone two, you'd still be better off than when it started. That's the test each milestone is planned against.
Tradeoffs get stated in business terms
Technical decisions are explained as what they cost, how long they take, what risk they carry, and what they make easy or hard to change later. If a choice saves money now and constrains you in two years, you'll hear both halves.
Bad news travels fast
Assumptions, risks, dependencies, and missing information get raised the week they appear — not in a status report a month later, when the options have narrowed and the fix has gotten expensive.
You own everything
Source code, data, credentials, and documentation live in your accounts under your name from the first milestone. Continuing with hij2 should be a choice you keep making, not a dependency you can't unwind.
How an engagement actually unfolds
From first email to a system your team relies on. Timelines vary by scope; the sequence doesn't.
-
Intro conversation — no charge
You describe the process and what it costs you. The aim is a shared read on whether this is a fit, and whether a discovery sprint is even warranted. Sometimes the answer is a suggestion and a handshake.
-
Discovery & architecture sprint
Fixed fee, fixed duration. The process gets mapped, the data gets inspected, integrations get tested for feasibility, and you receive a costed delivery plan you own outright.
-
Decision point
You decide whether to build, to build a smaller piece, to hand the plan to someone else, or to do nothing. There is no obligation attached to the discovery deliverables.
-
Milestone build
Work proceeds in milestones with demos and written acceptance criteria. Between milestones, priorities can be reordered based on what the demos revealed.
-
Pilot and cutover
A small group runs the new workflow on real data before anyone depends on it. Then migration, training, and documented handover.
-
Support, or a clean exit
Either an ongoing retainer, or a complete handover with documentation good enough for someone else to pick it up. Both are normal endings.
One engineer, twenty years, plain conversation
hij2 is a solo software engineering consultancy. The person who takes your first call is the person who maps the process, writes the code, runs the demos, and answers the phone when something misbehaves. Nothing is handed to a delivery team, and nothing gets lost in translation between the two.
Twenty years of building and maintaining software is worth stating for one reason: it lowers delivery risk. Long experience mostly shows up as judgment about what not to build, an instinct for which integrations turn ugly, and a willingness to say early that a plan won't hold — while changing it is still cheap.
The tradeoff is capacity. hij2 works with a small number of clients at a time, which means the schedule is honest and occasionally means the answer is "not until next quarter." You'll be told that up front rather than discovering it mid‑project.
The best outcome of a first conversation is sometimes finding out you don't need custom software yet.
If you'd like a technical reference, a look at prior work relevant to your situation, or a conversation with someone who has run a similar project, ask — that gets arranged with the client's permission rather than published here.
Bring the process that causes the most rework
The more concrete the description — who touches it, how often, what breaks — the more useful the first response will be.