Rescue and Recovery
Have Technology? Wish it was better?
Did your last partner drop the ball? Did you get what you wanted? Do you have a codebase that doesn’t meet your needs and you’re trying to figure out how to pick up the pieces?
Our greatest impact has been for companies that already have a technology solution that isn’t working for them. Maybe you built it yourself. Maybe it was an outsourced project that never became what you hoped it would. Either way, we can help you map a way out of the problem.
First, if your project is launched or in beta, we have to make sure that any changes we make won’t impact your customers. Establishing effective end-to-end testing is the first step. We’ll work with you to analyze the code you have and use automated testing to codify your product design so that, no matter what changes we make, your project will still perform as expected.
A trustworthy codebase is essential to improvement and meeting your goals.
Next, we’ll refine your codebase, remove duplication, simplify logic, and set you up for success.
Finally, we’ll begin to ramp up development to meet your key goals, knowing we are working with a trustworthy codebase.
While the cost of a rescue project can vary substantially – sometimes as little as $50,000 – we recommend that you budget $400,000. Sometimes, though rarely, a complete rewrite is necessary. Our process, plus the product-definition work we’ll do in step 1, ensures that we can deliver feature for feature with the same UI. We can do it cost-effectively and, in most cases, we take the risk of building the replacement codebase before we even broach the subject with you, so we can be sure. We have a solid track record of seamless cutovers in these cases, as well as projects where platform transition was the fundamental goal, so taking this step is as normal as doing any other kind of work.
How We Work
We start with your expertise
You know your business, your customers, and the realities of your work. We bring deep technical experience, curiosity, and a habit of asking good questions.
Rather than arriving with a predetermined answer, we work alongside you to understand what is happening, what matters most, and what a useful next step looks like. Our job is to help you make informed decisions and turn them into software that works in the real world.
We meet you where you are
Not every challenge needs a full-time, multi-person development team. Sometimes you need a second opinion, a technical plan, maintenance for an existing product, or help getting a stalled project moving again.
We can begin with a focused advising session, a lightweight consulting engagement, ongoing maintenance, or a small development milestone. When the work calls for it, we can grow with you into a longer-term product-development partnership.
We deliver in useful increments
We organize work around clear priorities and working outcomes. You can expect regular communication, direct access to the people doing the work, and a shared understanding of what is being built and why.
By delivering software in small, complete units, we can learn early, adjust when needed, and keep progress visible. That approach helps us avoid unnecessary complexity while building a foundation that can support what comes next.
We are a local partner with a national reach
Radial is based in Loveland and connected to the Northern Colorado, Denver, and Boulder technology communities. For regional clients, we can offer a more personal working relationship and opportunities to meet in person. We also work remotely with teams across the United States.
Whether we are helping you solve one immediate problem or becoming part of your long-term product team, we aim to be a steady, curious, and committed technical partner.
State of Your Codebase
Your codebase may be in a number of states:
- Pre-development
- You don't yet have a domain and/or the state of your codebase is unknown
- In Development
- An existing vendor or internal developer has built some functionality that you may or may not have seen in a demo
- In Alpha or available internally
- You have seen a demo of your app and may be able to access it but it is not available to the public in any form
- In Beta or available as a staging environment
- Your app is available to select groups within the public or available online, but not at your primary domain
- Launched
- Your app may not be feature-complete but it is broadly available to the public and/or on your domain
- Transferred
- You have unrestricted access to the codebase or the code, the deployed app, the domain your app is deployed to, and can transfer that access to others
Testing
Testing is non-negotiable. We now have roughly 50 years of data that shows that testing results in more reliable outcomes, smaller codebases, fewer bugs, and fewer security problems. Perhaps more importantly, writing tests first actually improves the efficiency and lowers the time of development for a feature. Not only does it ensure that complex repetitive work to test a feature is automated, it also helps to reduce the creation of unnecessary, sometimes called “speculative” code.
Kinds of testing
- Unit Testing
- Tests abstract business logic to ensure that it is correct. Experts recommend that this be the majority of tests
- Integration Testing
- This ensures that software internals work together as expected.
- System Testing or End-to-End Testing
- This is the most common kind of test we write as it verifies that a given feature works, as implied, from end-to -end. This also ensures that new features do not unexpectedly change or break existing ones.
- Acceptance Testing
- Typically we pair System tests to customer specifications, but at times, additional testing automation is added to ensure that each deliverable is consistent and complete.
- Smoke Testing
- You may have heard of this type of test. Typically these are included to ensure the testing tools are, themselves working as desired.
- Sanity Testing or QA Testing
- This is a manual quality check of an application. We write testing instructions and key aspects of the software are tested. We added to these scripts over time. It is helpful to ensure that human eyes are evaluating product to ensure that there are no undesirable facets developing in the experience.
- Automated QA
- As above this is a scripted review of site functionality, but is not done manually. This may be a recorded script or may only result in video artifacts that are reviewed by QA personnel.
- Canary Testing
- When possible, it is advisable to release new code to a small fraction of your users. Ideally, the best canary testing is done with tens or hundreds of thousands of users representing small percentages of your users.
Trustworthy Code
Breaking something when you’re trying to fix something else is the worst.
Being able to modify your software is essential to being able to correct issues, fix bugs, and meet market demands on a reasonable timescale. At the same time, one of the greatest risks is changing code where the purpose and function is unknown. If your code is being written by a single developer, the code can be as trustworthy as the memory of the developer, but since serious development is done not only by multiple people, sometimes, multiple teams, there is no way to create the relevant memory. The code must have a way to remember its own purpose. Automated testing is one of the best ways to ensure that the purpose of code is kept and that later versions do not lose this purpose. This also allows appropriate changes when the purpose changes since the alternative is to keep code the same when its purpose is unknown, even when the intent is no longer consistent with the code.
Because the expectation that developers will always run tests is based on the idea that developers never make mistakes or skips steps, a continuous integration (or CI) system can be implemented to ensure that nothing enters the codebase in a known-bad state. This also ensures that developers can always begin work from a known-good state of the code.