Software consulting and modernization

Three kinds of work: assessment, roadmap, modernization

You have a decision to make about software, but nobody has told you in writing what state the system you have is really in. This page is for that situation. Software consulting and modernization here means assessing the software you have, writing down where it should go and, when it is needed, rebuilding it. There are three kinds of work; which one you start with depends on what you have.

These are not strategy decks; they are written outputs grounded in the code, the system and the access. If a ready-made solution, or leaving things alone, suits you better, we say so. The assessment is work like any other: its scope and cost are in a written proposal before you approve anything.

What does the written assessment report contain?

The assessment method rests on the audit plan we published for an unfinished project; the plan is a template divided into steps, and the report is its output. This page summarizes it; the detail is in the article.

Instead of a percentage or a time estimate, the report states measurable conditions and reasons: "what percent is done" misleads, while "works, half-done, missing" can be checked.

Rewrite, or modernize step by step?

There is no rule that holds for every system; there is a reasoned decision that depends on the state of yours. The questions below show which way each one pulls the decision; they do not deliver a verdict.

The two extreme views are well known. Joel Spolsky argued that rewriting working code from scratch can be a strategic mistake (Spolsky). Martin Fowler describes building the new system beside the old one and moving functions over gradually, instead of replacing the old system in one move (Fowler). Starting from scratch is sometimes right, and an assessment will say so. For the whole decision framework, see legacy software modernization: rewrite or replace step by step?

An unfinished project: where do you start?

The first step is not technical: secure the access and the accounts. If the domain sits in the previous developer's account, your site and your email stay tied to them; reading the code can wait, this cannot. Then comes the assessment, and the decision last.

Why the project stalled changes what the assessment looks at: did the scope grow, did the team disappear, did it hit a technical obstacle? The detail is in how to take over an unfinished software project.

As we say on our home page, you can come with an idea, a need or a half-finished project. The method and the duration depend on the state of what you have and are set out in the written proposal.

If the decision comes out as "continue," partial rewrite or start over, the new scope runs as custom software development, and the approach on the MVP development page helps with cutting the scope. If what stalled is a prototype generated with AI, start with the audit in is your vibe-coded app production ready.

How we work

Every piece of work goes through the same four steps from the first conversation to delivery; the Process page has the details.

1. Discovery. We talk until both sides describe the same thing: the system you have, the access, and what a good result looks like.
2. A scoped proposal. The scope, the order and the cost of the assessment are written down; if a project follows it, its scope is settled the same way, in a written proposal. Nothing starts until you approve.
3. Building, visibly. Once we are building, a live project panel opens in your account; you see real progress there.
4. Review and handoff. You review the report and any work done, we refine it, and then we hand it over.

You talk directly to the engineer writing your code, and we work only with senior engineers.

What to have ready for an assessment

You do not need to prepare. These things sharpen the conversation:

• Access. The repository, hosting, domain and third-party accounts. Access you share for infrastructure work is stored encrypted and used only for your project.
• Documents. The contract, the scope document, earlier proposals.
• Today's use. Who uses the system, and with what data?
• Constraints. Regulation on the data and internal rules.

If you do not have all of this, that is fine: missing access or documents become one of the report's first findings.

What drives the price

We do not quote figures or durations on this page, because a number given before the scope is clear is only an estimate. Scope, timeline and cost appear in a written proposal before work starts, and the price does not change once the scope is approved in writing.

Treating the assessment and the project after it as separate items takes the price out of the realm of guesswork. We explained how to read a written proposal in how to read a software proposal. What is binding is the written agreement signed for your engagement; this page does not replace a proposal.

Your way out: source code, access and handover

The report is written so that you can read it and decide. Once the project is paid in full, the delivered work is yours; our own tools, libraries and frameworks that existed before your project stay with us, and the provision is on the Terms page. If a project follows the assessment, then unless you would rather handle it yourself, we provision and manage the infrastructure; if you have your own accounts, we deploy there. If you ever want to move it, we help you transfer it cleanly with accounts, domains and documentation. Nothing we run for you is a reason you cannot leave.

Who we are not a fit for

• You only want a strategy deck or management consulting. What we deliver is a written assessment grounded in the code and the system, and working software.
• You expect an opinion without sharing the system, the code or the access. An assessment needs access and a setup run; we cannot tell you the state of a system in writing by looking at it from outside.
• Your only criterion is the lowest price. Weighing an engagement with a written scope, a price that does not move afterwards and senior engineers against a price-led quote on one scale misleads both of us.

Frequently asked questions

How is software consulting priced?

Scope, timeline and cost appear in a written proposal before work starts, and the price does not change once the scope is approved. We do not quote figures or durations on this page, because a number given before the scope is clear is only an estimate. The items that set the cost are in the "What drives the price" table above.

Do you take over code written by another company?

As we say on our home page, you can come with a half-finished project. We recommend, and write down the reasoning, whether building on what you have or starting over is the right call; the decision is yours. The method and the duration depend on the situation and are set out in the written proposal; the full step-by-step audit plan for a takeover is published.

What determines the length and scope of an assessment?

The size of the code, the state of documents and access, the number of platforms and integrations, and the volume of data. We do not quote a duration on this page; the duration and the method appear in the written proposal together with the scope.

Which technologies do you work with?

Across our portfolio we mostly used Node.js and PostgreSQL for business systems, and React and Next.js for interfaces. If your system is on a different stack, we tell you plainly in the first exchange whether we are the right team for it.

Do I have to implement the findings with you?

The decision is yours. The report is written so that you can read it and decide, and the next step is a separate written proposal. Nothing we run for you is a reason you cannot leave.

Can we move over without shutting the old system down?

For some systems, yes: building the new system beside the old one and moving functions over step by step is an option, but it does not suit every system. While the old system keeps running, the move needs a parallel run and a data migration plan. The real plan depends on the system you have and appears in the written proposal. To test which way suits yours, use the rewrite-or-replace decision test.