This is who
we are.
A document for anyone who speaks for Beyond Code. Not marketing copy. Not sales pitch. Just the truth about what we believe and why we do what we do.
The Mission
We shape how developers work—today and tomorrow.
That's not a tagline we came up with in a meeting. It's a description of what we actually do. When a developer sits down to write code, they reach for tools. Some of those tools are ours. And if we've done our job right, those tools disappear—they just work, and the developer can focus on what matters: building something.
We started in 2017 as a small team in Germany. We're still small. We like it that way. Being small means we can move fast. It means we can say "this is annoying" on Monday and ship a fix on Tuesday. It means we can care about the details that bigger companies would call "out of scope."
The "tomorrow" part of our mission isn't about vague futurism. It's about the fact that development is changing—AI agents are joining the workflow, codebases are getting more complex, and the line between "writing code" and "orchestrating systems" is blurring. We're building for that world. Not because it's trendy, but because that's where our users are heading, and we want to be useful when they get there.
What We Believe
These aren't values we put on a poster. They're the things we actually argue about in Slack, the principles that settle debates when we're stuck on a decision.
Developer First
We build for the person writing the code, not the person approving the budget. That might sound obvious, but it's not. A lot of developer tools are built to look good in procurement demos or to check boxes on feature comparison charts. We don't do that.
When we're deciding whether to add a feature, we ask: "Does this make a developer's day better?" If the answer is no—or even "maybe, but mostly it helps sales"—we don't build it. This keeps us focused. It means we ship less, but what we ship actually matters.
Craft Over Compromise
We sweat the details that other companies skip. Fast startup times. Keyboard shortcuts that make sense. Error messages that actually help. UI that doesn't fight you.
This isn't perfectionism for its own sake. It's recognition that developers use their tools for hours every day. A half-second delay in startup time is annoying the first time. After a month, it's infuriating. So we care about that half-second. We care about whether ⌘K does what you expect. We care about whether the icons are clear at small sizes.
Craft means we'd rather ship one great feature than three mediocre ones. It means we sometimes say "not yet" to requests that would make the product worse overall. It means we refactor code that's already working, because "working" isn't the same as "good."
Open By Default
Everything we know, we learned from open source. Laravel. Tailwind. The countless packages and blog posts and Stack Overflow answers that make development possible. We built our careers on other people's generosity. So we give back.
We maintain over 50 open source packages with millions of downloads. We speak at conferences. We write documentation. We answer questions. Not because it's good marketing (though it is), but because it's right. The Laravel community gave us everything, and we owe it a debt we'll spend our careers repaying.
"Open by default" also means transparency. We tell you when something's broken. We explain our decisions. We don't hide behind corporate speak. If we screw up, you'll hear about it from us first.
Built for Humans and Agents
The future of development isn't humans vs. AI. It's humans with AI. We're building tools that work for both.
Practically, this means CLI-first design—every action you can do in the GUI, you can do from the command line. It means MCP (Model Context Protocol) integration, so AI agents can interact with our tools programmatically. It means sensible APIs and clear documentation.
We don't know exactly what development will look like in five years. But we know that developers will still be at the center of it, and they'll have powerful assistants helping them. We want our tools to be useful in that world—whether you're typing the commands yourself or your agent is.
How We Sound
Bold and playful. That's the short version. Here's what that actually means:
We Say
- + "Your code. Running. Now."
- + "Development, perfected."
- + "Share localhost with the world."
- + "We build tools that disappear."
We Don't Say
- − "Enterprise-grade solution for..."
- − "Leverage synergies across..."
- − "Revolutionary paradigm shift..."
- − "Best-in-class integrated platform..."
We talk like developers because we are developers. We use technical terms when they're the right terms. We make jokes when something's funny. We're direct when we need to be.
"Bold" means we're not afraid to have opinions. We'll tell you that Valet is slow and that's why we built Herd. We'll tell you that most PHP debugging workflows are painful and that's why we built Tinkerwell. We're confident in what we've built, and we're not going to pretend we're not.
"Playful" doesn't mean unprofessional—it means human. We use contractions. We write short sentences. We occasionally use em dashes when we get excited about something. We're building tools for creative work, and that should come through in how we communicate.
Visual Identity
Our visual identity follows the same principles as our products: bold, clean, and purposeful. Dark backgrounds with bright accents. High contrast. No clutter.
Product Colors
Each product has its own color. These aren't arbitrary—they help developers quickly identify which tool they're looking at, and they create visual consistency across our ecosystem.
Typography
We use Space Grotesk for its technical but approachable feel. It's geometric without being cold, modern without being trendy. Headlines are uppercase and tightly tracked—bold and assertive. Body text is lowercase and readable—clear and helpful.
Design Principles
High Contrast
Dark backgrounds, bright accents. No muddy middle grounds. Things are either foreground or background.
Purposeful Motion
Animation draws attention to what matters. Marquees for energy. Hover states for interactivity. Never decoration for its own sake.
Clear Hierarchy
One thing is the most important. Everything else supports it. No competing calls to action, no visual noise.
The Team
We're a small team. Three people, based in Germany. That's not a limitation we're apologizing for—it's a deliberate choice.
Sebastian Schlein runs the business side. Strategy, sales, marketing, operations. He's the one who makes sure we can keep building things without worrying about whether the lights stay on. He also writes about building software products, because he believes the best marketing is just being useful.
Marcel Pociot is the inventor. He built Tinkerwell because he was annoyed. He built Herd because he was more annoyed. Most of our products started as Marcel solving his own problems and then realizing other developers had the same problems. He speaks at conferences around the world, mostly about the intersection of PHP and making things that don't suck.
Diana Scharf is a full-stack developer who works on everything. Tinkerwell features, bug fixes, documentation, you name it. She speaks at conferences across Europe and mentors women in technology. She's proof that you don't need a huge team to build products that people love—you just need people who care.
We're not going to grow to 50 people. We're not going to raise a Series A. We're going to stay small, stay focused, and keep building things that matter. If that means we ship fewer products than a larger company could, that's fine. We'd rather ship four great products than twenty mediocre ones.
What This Means in Practice
If you're writing copy for Beyond Code, designing something, or speaking on our behalf, here's what all of this means:
Be specific.
Don't say "improve your workflow." Say "switch PHP versions in two seconds." Features are specific. Benefits are specific. Vague is boring.
Be confident, not arrogant.
We're proud of what we've built, and we should sound like it. But we're not claiming to be the only solution or the best at everything. We're great at what we do. That's enough.
Talk to developers like developers.
Our audience knows what PHP is. They know what a local development environment does. Don't explain basics. Use technical terms correctly. If you're unsure about something technical, ask.
Keep it short.
Developers are busy. Respect their time. If you can say it in five words, don't use fifteen. Headlines should punch. Paragraphs should end before you think they should.
Show the work.
Screenshots. Code samples. Terminal output. Developers don't believe marketing—they believe evidence. The more you can show what the product actually does, the more compelling your message will be.
That's the brand. Not a rulebook—a compass.
When in doubt, ask: "Is this useful to developers?"
If yes, you're probably on the right track.