Hey! 👋
This handbook explains how we work. It is a tool for clarity, not a collection of rules to be memorized.
Translations: German
1. Why WeMake Exists
We transform organizations with responsible AI. The objective is to enable people to have more impact, make work more meaningful, and help companies learn faster. We build solutions for actual problems: operational, strategic, and human. Our approach is German-first in quality, ethics, security, and language—globally aware, but with a precise understanding of the local context.
- Work is a practice. Good work requires a principled stance, craftsmanship, and robust systems.
- Technology is not an end in itself. It is an amplifier of intent. Useful if the direction is sound, dangerous if it is not.
- Responsibility is not a buzzword. It is a daily, operational decision, visible in our code, contracts, consulting, and support.
- We measure ourselves by impact. What is demonstrably better after 30, 90, and 365 days? For users, teams, clients, and society.
Our operating assumption is that people are capable of more than typical job descriptions permit. Consequently, we design work to enable you to create multiple solutions, not just single features. This includes:
- Broad ownership (Problem → Solution → Operation → Learning).
- Access to our "infrastructure of competence" (Clarity, V41).
- Coaching, documentation, and feedback loops.
- Clear, publicly traceable decisions (PRs, RFCs, Architecture Decision Records).
- Tools that get out of the way instead of complicating work.
- We connect strategic consulting with executable technology.
- Clarity is our organizational intelligence layer; V41 is the multimodal foundation.
- Our consulting is not separate from the product—it operationalizes our mission, ethics, and architecture.
- We build, curate, and orchestrate solutions along real value streams: sales, operations, support, compliance, product, people.
- Our toolbox (Clarity/V41) enables specific, repeatable solutions—industry-aligned but not hardened into bespoke dead ends.
- We prioritize Time-to-Learn over Time-to-Launch. We favor rapid, valid learning cycles over "perfect" roadmaps.
- Our default is to build iteratively in public: changelogs, demo environments, open docs, public discussions.
The only secret here is the irony. The plan is public.
- Today (Current State): Consulting, orchestration, and implementation with Clarity/V41; productive deployments; transparent guidelines.
- Next 12–24 Months (Target State): More self-serve capabilities, smarter automation patterns, intensive readiness checks, a broader library of reusable solutions; expansion of our German language and cultural competence in models.
- Long-Term: WeMake as the reference for responsible, effective AI in the German-speaking world; an infrastructure provider, not a project shop.
2. How We Got Here
Influences that have shaped our thinking.
- Systems thinking, antifragile organizations, ethics in technology, humans in complex systems.
- Practices: RFCs, Design Docs, Postmortems, operational learning, decision journals.
- Stance: Clarity, courage, consequence.
- Open-source communities (governance, reviews, contribution culture).
- Security and cloud pioneers (Zero Trust, resilience, automation).
- Product teams that treat documentation as a product.
- This handbook is alive. We commit to it. We version it. We review it.
- It exists not to be right, but to become better.
- If reality and the handbook diverge, reality wins—and we update the handbook.
- Open Source → Our Operating Model: Public, traceable, contributions welcome.
- Urban Infrastructure → Our Platform Strategy: Clarity/V41 are the roads, power, and water. Products are built upon them.
- A Gym, Not a Spa → Our Culture: You are here to train your capacity for responsibility and skill. Comfort is a byproduct, not the goal.
3. How We Acquire Users
- We solve real problems, not hypothetical ones.
- We speak our users' language (literally: German; professionally: the language of their domain).
- Trust is our currency, earned through transparency, security, and clear expectations.
- Content is our marketing. From deep dives to practical guides.
- We do not offer "Hype as a Service." We explain how things work—and how they fail.
- We share what we learn: benchmarks, metrics, trade-offs, decisions, and their costs.
- The website is a product. It is the first experience of WeMake.
- It enables self-service: demos, docs, sandboxes, direct sign-ups—ideally without a sales call.
- It is fast, accessible, searchable, understandable, and current.
- It states what we do and, just as importantly, what we do not do.
- Freemium/trials, clear usage models, simple contracts.
- Shortcuts, not hurdles: direct purchase, pilots, pay-as-you-go.
- No hidden fees. Pricing is explained, not obfuscated.
4. Who We Build For
- Organizations in the DACH region with high standards for quality, security, and ethics.
- Teams prepared to work with AI operationally, not just discuss it.
- Regulated domains: healthcare, finance, industry, public sector, education—where diligence is mandatory.
- People who take equality, empowerment, and purpose seriously and are willing to accept the consequences (ownership, learning curves, feedback).
- The practitioner: the person who runs the process, who deals with the error, who actually saves or loses time.
- Leaders responsible for impact, not just spreadsheets.
- Colleagues who will join later. Documentation is a welcome package.
- High-potential: Clear pain points, data access, operational readiness, a sponsor with ownership.
- Why it matters: We want results. This means fast learning cycles, repeatable patterns, and scalable solutions.
- Hobbyist: Someone who experiments without a real-world application or commitment.
- Why it matters: We are helpful but focused. We assist where we can, but we prioritize impact.
- Because execution matters: data, processes, security, governance, integration.
- The AI team ensures repeatable quality, not just colorful demos.
- Marketing is part of the product: content, demos, documentation, community.
- Its goal is to enable understanding and lower barriers.
- Sales is consulting, not pressure.
5. How We Make Users Happy
The term "happy" is imprecise. We aim for "effective," "capable," and "confident." Happiness is a potential outcome.
- We start with the job-to-be-done, not the feature list.
- We measure impact: time saved, error reduction, quality improvements, user satisfaction.
- We build small and learn fast: Proof → Pilot → Production.
- We document what we learn—publicly, when possible.
- There is no scripted support queue. You speak with the people who built the solution.
- Review and support calls are short, specific, and solution-oriented. We are async-first and document everything for traceability.
- We are honest about trade-offs and help you make the right decision for your context.
6. How We Make Money
- Self-serve and low-touch where possible. High-touch only where necessary.
- Content, demos, and readiness checks lower acquisition costs and increase customer fit.
- We do not sell hypotheticals. Our solutions are usable, not just presentable.
- Transparent models. Low-friction entry points.
- We prioritize utility over margin maximization. This is sustainable, not naive.
- We invest in efficiency and automation to keep prices low over the long term.
- Pay-as-you-go, caps, limits, and alerts. You control your costs.
- Data and metric exportability is a standard feature, not a premium one.
- Canceling is as easy as signing up.
- We optimize for Total Cost of Ownership (TCO), which includes implementation, operation, and risk.
- If an open-source alternative is cheaper and sufficient, we will recommend it—even at the cost of short-term revenue.
- We earn trust before we maximize revenue.
- It is acceptable to lose deals if it means adhering to our principles.
- We do not commit to specific deliverables in contracts; we commit to outcomes against defined goals and metrics.
- We build things when we are convinced they can be used by more than one organization.
- Clients must try solutions before requesting changes. Learning beats hypothesizing.
- Product Management/CSM is not a default role, but a lightweight, temporary tool we deploy when scale, coordination, or compliance requires it.
- Security and ethics are non-negotiable.
7. Sustaining Low Prices
- Problems rarely exist in isolation. A customer with one solved problem often has another. We deliver modular, integrable solutions.
- Cross-solution design saves implementation costs.
- Documentation, demos, sandboxes, and online purchasing lower the barriers to entry, allowing you to decide for yourself.
- Sales is a consultative function, not a persuasive one.
- Clarity as the orchestrator, V41 as the core. This provides unified identities, metrics, and governance.
- Less integration, fewer data silos, lower costs.
- We write docs that are actually helpful: how-tos, playbooks, architectural diagrams, decision guides.
- We invest in examples, SDKs, and templates to prevent support tickets.
- We use what is effective and contribute back where we can.
- Open source is also a governance model: public, reviewable, forkable.
8. Deciding on New Solutions
- Guiding Question: Whose problem are we solving, and how quickly can we learn from it?
- Criteria: Utility, reusability, security, complexity, maintenance load, documentability.
- Formats: RFCs, Architecture Decision Records, small experiments, public changelogs.
- We create a new solution when a problem cannot be logically integrated into an existing one, or when a new bundle of capabilities emerges.
- We avoid creating a product graveyard. Every solution has a clear owner, clear metrics, and clear exit criteria.
- Before we build, we write the documentation we will need later: installation, runbooks, troubleshooting, security, ethics, metrics.
9. A Broad Company with Small Teams
- Speed is a function of small batch sizes, clear responsibilities, and publicly traceable decisions.
- We optimize for throughput and learning velocity, not for resource utilization.
- Small, autonomous cells with end-to-end responsibility.
- Teams have what they need or they build it. We minimize dependencies.
- Leadership is an activity, not a rank.
- We lead through clarity, not control.
- Your title should reflect your output, not your aspiration.
- Career paths are built on expanding competence, not climbing a ladder.
- We use clear, measurable goals with tight feedback loops.
- "Ship small, learn big": small releases, large learning effects.
10. How We Build a World-Class Team
Personality traits that correlate with success at WeMake.
- You want to bring things into the world. You can abstract and execute.
- You build systems that make others better.
- You communicate clearly, kindly, and precisely.
- You work asynchronously and respect focus time.
- Success is a team outcome. You share credit and learn from failures.
- You address conflict early, openly, and with a focus on resolution.
- You do not wait for permission; you acquire context and begin.
- You are responsible for impact.
- You want to work on the front lines of applied AI ethics, security, and efficacy.
- You want to work remotely, autonomously, and with clear impact.
- You want to learn, document, share, and elevate others.
- If you value comfort over responsibility.
- If transparency makes you uncomfortable.
- If you prefer to be managed rather than to lead.
- A few strong people outperform large, average teams.
- Compensation is fair, transparent, and competitive, with ownership options where appropriate.
- We compensate for impact, not presence.
11. What We Value
- Context > Control. We provide direction; you find the best path.
- We expect you to make decisions and explain them publicly.
- Public by default: PRs, issues, docs, roadmaps—everything that does not need to be confidential.
- Public exposure is a quality filter and a teacher.
- Convention is comfortable; progress is not.
- We look where others do not, and we explain what we find.
- Today is better than "soon." Start small, learn big.
- Name risks clearly; do not avoid them.
- We are realists with a forward-looking bias.
- Problems are invitations to design better systems.
12. Creating a World-Class Work Environment
- Our default state: Engineers, Researchers, and Designers speak directly with users.
- We activate Product Management/CSM as a lightweight, temporary function where enterprise context, coordination, or compliance demands it.
- The goal: Fewer layers of translation, more shared understanding, faster learning loops.
- Every significant decision has a corresponding PR, issue, or ADR.
- Minutes, postmortems, and metrics are standard practice.
- Security and ethics are documented alongside functionality.
- We hire people who want and can handle responsibility.
- We assess skills, stance, and ability to learn. We coach and test in practice.
- Technology is our medium; diversity is our amplifier.
- We are mindful of language, opportunities, and spaces to ensure competence is visible.
- Async-first, protected focus time, few meetings.
- Communication is written, concise, and respectful.
- Slack is for coordination; decisions live in PRs and issues.
13. Not Running Out of Money
- We prioritize runway and impact over growth at all costs.
- We run scenarios and maintain early warning systems.
- Capital is a tool, not a goal.
- We only accept funding on terms that protect our principles.
- Transparency with the team and community is a priority.
- On infrastructure that enables many solutions (Clarity, V41).
- On people who build systems, not just close tickets.
- On content that provides utility: docs, playbooks, research, benchmarks.
14. Where We Are Going
- We are building for independence. A sale is not a goal, but a possible event—if it strengthens the mission and its people.
- We prefer secondary sales to full acquisitions.
- A specific, measurable goal. This represents recurring value and impact, not just revenue.
- We will publish key metrics that illustrate the journey (without sharing confidential information).
- Employees should have the opportunity to realize value without selling the culture or mission.
- We prefer options that secure stability while enabling growth.
15. How You Can Help
- Read this handbook and our core documents.
- Start with a small, useful contribution: improve a piece of documentation, write a small script, add a test, define a pattern.
- Show your work: what you did, what you observed, what failed.
- Ask specific questions so we can provide specific help.
- "Perfect" is often slow and fragile. "Clear, functional, and documented" is our target state.
- Mistakes are acceptable; hiding them is not.
- Leave everything a bit clearer, simpler, and more secure than you found it.
- Write the documentation you wish you had when you started.
- Ownership means taking action. Get context, decide, document, iterate.
- If you are blocked, state it early.
- Say what you think—reasoned, respectful, and with a willingness to be wrong.
- If you change your mind, document why.
- Look for the third, fourth, and fifth solution patterns.
- Combine existing components in new ways. Clarity AI is designed for this.
- We work in teams. Issues describe problems; teams commit to solutions.
- Responsibilities are clear but not personified in the tracking system.
- A minimum of one review for code, docs, and decisions.
- A review is about sharing responsibility, not bureaucracy.
- Decisions and changeable proposals belong in Pull Requests.
- Ideas and problems belong in Issues.
- Slack is for coordination and human connection.
- If it is important, it does not live only in Slack.
- Public is the default; confidential requires justification.
- Write for a future reader: be brief, clear, and provide links.
- Answer in a way that is helpful, friendly, and honest.
- If you don't know the answer, say so, and then find it.
- You are free to read, cite, and critique this handbook.
- If you believe something is missing or incorrect, open an issue. We would be grateful.
Internal references and sources are linked where appropriate. These documents are publicly accessible unless they contain confidential information.