Meet the founders, talk over the high-level problem and our approach to software.
Get a map of the territory for consideration. If the mission is to assess many systems for candidate projects, go wide. If the target is already known, begin probing deeply into its architecture for pain points and opportunities.
While we'll play our understanding back to you along the way, to make sure we understand - the destination of this journey together is a short proposal including goals, technology suggestions, an estimate of time, and cost options.
Are driven by their goals and dreams, and are looking to expand their team's skills and knowledge.
They should be able to speak intelligently about the things that matter to them and have an open-minded attitude toward technology.
Their company values results over details, and is open to different solutions to problems, so long as they are realistic about costs.
They understand that software is an integral part of their business process, and want to work with someone who shares this view.
They manage by objectives, not by process, and trust their technology partner to manage the strategy.
They have a large amount of data to deal with and need systems that can help them process it efficiently.
They recognize the value that the right technology can bring to their ecosystem and are looking for someone who understands the problems they face and can be an advocate for their brand.
When it comes to legacy refactors, we *always* take the existing tech stack into account, and recommend upgrading only when it will actually produce ROI for the client. If you are using C# or Java, that’s probably fine. If you are using COBOL/VB6, probably not!
Our baseline tech preferences:
In the real world, it’s usually a mix.
The method we use is to write a plain English design document talking through your goals (for example, you may prefer managed services to not have to maintain as much software) and mapping those goals to technology choices.
As a general matter, we believe edges of systems (interface points) should be custom, so you can vary the technology behind the interfaces without as much pain. That is, when a given product goes end-of-life and you must replace it, an interface will save a lot of time and money.
Also, instrumentation is best left flexible, so having firebreaks throughout the system where you can emit custom logs and other performance information allows for much more robust monitoring, alerting, and overall a better experience from the business point of view (to say nothing of the improvement in DevOps quality of life, and thus cost).
We tend to make extensive use of third-party tech by default, but contained within a matrix that is under the full control of the client, to maximize ROI while minimizing several often-overlooked forms of risk:
That is up to you. We are happy to provide:
Whatever you want is fine with us. We’ll make an agreement and deliver.
Bespoke – the elite companies we’ve worked for as full-time employees universally scorned faddish development approaches. We expect team members to own goals and be their own QA departments. However, “the SDLC” – the software development life cycle – at Adiuvat is essential:
We give engineers units of work (and responsibility) large enough to let them act like owners. This not only ensures they grow professionally but increases efficiency over other approaches. We reject the scrum-versus-waterfall dichotomy.
Heavy user-interface projects that are customer-facing are best served by firms dedicated to that type of product development. Additionally, we do not do mobile development beyond relatively simple evolutions of existing products.
If you have a super-specialized ask, e.g. “reduce my AWS bill by $250k”, or “perform a penetration test of my website or API portal” – there are specialized firms we can recommend that will crush this for you. We don’t need to be a middleman. However…
We have no problem acting as a general contractor if you have a multi-part project that will require competencies outside our norms, but our core organic competency is backend development, so projects we take on will naturally always contain significant backend work.
