Our Principles
How we work — and how we decide what to work on.
We're a small company that does SAP consulting and builds its own tools. These principles have shaped how we've operated for nearly two decades. They're not a manifesto — they're patterns we've noticed in the decisions that turned out well.
Solve the real problem
Most SAP projects don't fail because of technology. They fail because someone solved the wrong problem — the one in the slide deck instead of the one in the landscape. We start by understanding what's actually there: the systems, the constraints, the history. Then we figure out what actually needs to change.
This means we sometimes push back on the brief. If a customer asks for a custom integration but the real issue is a misconfigured RFC destination, we say so. The goal isn't to bill hours — it's to leave the landscape in a better state than we found it.
The same principle applies to our tools. YaNco exists because the standard SAP .NET Connector made functional programming impossible. Our DMS migration framework exists because no tool handled SAP DMS link tables correctly. We build what's needed, not what's fashionable.
What we recommend, we've done ourselves
We don't just recommend architectures — we build the tooling that proves they work. When we recommend functional error handling for RFC calls, we can show them YaNco. When we say async replication is the right pattern, we can point to integration frameworks we've built and run in production.
This keeps us honest. Consulting without building is just opinions. Building without consulting is just code. The feedback loop between the two is what makes both better. Our tools come from real project work, and our consulting is grounded in what we've actually shipped.
It also means we operate what we build. We run our own infrastructure, manage our own deployments, and deal with the same operational realities our customers face. That experience feeds back into every architecture recommendation.
Own the outcome
Go-live is not the finish line. When we deliver an integration, a migration, or an architecture recommendation, we stay accountable for whether it actually works in production. Not because we have to — because the outcome is what matters, not the deliverable.
This is why Design, Build, Operate isn't three services — it's one philosophy. The person who designs the architecture should understand how it will be operated. The person who builds the tool should care whether it survives contact with real data. We don't hand off and walk away.
Accountability also means being reachable. When something breaks at 2 AM or an edge case surfaces six months after go-live, we're still the ones who pick up the phone. That long-term skin in the game changes how you design systems in the first place.
Open by default
Our default is to open-source our tools. YaNco, dotnet-ovn, our integration libraries — they're all public. Not because open source is trendy, but because it produces better software. Public code gets scrutinized, documented, and maintained to a higher standard.
It also means anyone can evaluate what we do before talking to us. Our code is on GitHub, our architecture patterns are documented. The depth of the work is the proof of competence — not claims on a website.
Open also means honest about maturity. Some tools are battle-tested across multiple customer deployments. Others are experimental. We label them accordingly and let people decide for themselves.
These principles in action
Want to see how this translates to real projects? Let's talk about your SAP landscape.