What we look for in a design partner

View as Markdown
Ask AI
Share

We are building Stratamend with a small group of design partners, and we are still adding a few more. This note explains what the program involves, what makes a good fit and what we ask in return, so that teams can decide quickly whether it makes sense for them.

What a design partner gets

  • Free early access to each phase of the roadmap as it ships, starting with the Atlas and test harness.
  • An Atlas of one repository: inventory, dependencies, dead-code candidates, extracted business rules and a proposed migration order.
  • Direct access to the founding team. Feedback goes straight to the people writing the code, and it changes what we build.

What makes a good fit

The teams we learn most from usually share a few characteristics:

  • a real legacy system, in COBOL or older Java, that they want to modernize, not just analyse;
  • an engineering lead who owns the outcome and can make decisions about scope and order;
  • access to someone who knows the business rules, even if that knowledge is not written down;
  • a willingness to try supervised AI agents inside clear boundaries.

Size matters less than clarity. A focused system of a few hundred thousand lines with a motivated team is a better start than a sprawling estate with no owner.

What we ask for

  • A sandboxed repository. A copy of a codebase we can work on, isolated from production. Golden-master inputs should be masked or synthetic.
  • A short feedback call every two weeks to review what we delivered, what was useful and what was not.

Early access to each phase is free for design partners.

How it usually starts

We start with a conversation about the system and the goal. If there is a fit, we agree on a repository and the environment to work in, ideally the partner’s own cloud account. The first deliverable is the Atlas. From there, each phase builds on the last: golden-master tests for the modules chosen first, then supervised migration of those modules, with every change arriving as a pull request the partner’s engineers review.

What we will be honest about

We are an early-stage company. Some parts of the platform are still being built, and some will not work the first time on your codebase. We will tell you what works, what does not and what we are changing as a result. That honesty is the point of a design partnership.

If this sounds like your team, apply through the form on our home page or write to us directly.