# Bkper — Platform Guide

Behavioral and domain context for building on the Bkper platform — technical instincts, quality standards, and product sensibilities.

Simplicity, essentialism, and speed with integrity aren't just values — they're survival strategies that enable a small team to deliver exceptional value globally.

## Technical Instincts

When you write code or architect systems on Bkper, certain principles are essential:

**Simplicity scales better than cleverness.** Reach for proven, boring technology over cutting-edge complexity. Build only what's essential — every line of code, every feature, every decision must earn its place.

**Data integrity is sacred.** In financial systems, eventual consistency isn't good enough. Protect the zero-sum invariant religiously — every dollar tracked must balance perfectly, extending this same rigor to any resource being tracked.

**Performance is user experience.** A fast system isn't a luxury — it's essential for users making rapid financial decisions about cash flow, expenses, and budgets.

**Security is foundational.** Bake security into every layer, knowing that the platform is trusted with sensitive financial data — bank connections, transaction details, and business intelligence.

**Global from day one.** Handle multiple currencies, units of measure, timezones, and formats as first-class concerns, not afterthoughts.

## Quality Instincts

**Tests are contracts with the future.** Tests aren't overhead — they're investments in confidence, documentation, and velocity. Reach for tests when fixing bugs, adding features, or refactoring code. A failing test that reproduces a bug is as valuable as the fix itself.

**Domain understanding precedes implementation.** Model the problem space before jumping to solutions, ensuring code reflects business reality rather than technical convenience. Think in terms of resources, their movements, and their relationships before writing the first line of code.

## Product Sensibilities

**Every feature has a cost.** Not just development time, but cognitive load, maintenance burden, and opportunity cost. Ask "Is this essential?" before "Is this worth it?" Choose the essential few over the trivial many.

**Convention over configuration.** Provide smart defaults that work for 80% of users while allowing power users to customize.

**Progressive disclosure.** Reveal complexity gradually, ensuring new users aren't overwhelmed while power users can access advanced features.

**Error messages are teaching moments.** When something goes wrong, help users understand why and how to fix it, using language they understand.


## How to Approach Problems

1. **Start with user pain.** Don't build features; solve problems. Every solution begins with understanding what's making users' lives difficult.

2. **Question the premise.** Before optimizing a workflow, ask whether it should exist. Before adding a feature, explore if you can eliminate the need for it. Ask "What can we remove?" before "What should we add?"

3. **Think in flows.** Whether it's cash flowing through accounts, inventory through stocks, or instruments through portfolios, visualize movement and identify where friction occurs.

4. **Consider the ecosystem.** Bkper exists in a broader financial context — banks, payment processors, accounting software, tax systems — while recognizing similar ecosystems exist for other resource types. Design for interoperability.


## Standards

**In Code:**

- Readable over clever
- Tested over "it works on my machine"
- Documented over self-documenting
- Maintainable over perfect

**In Design:**

- Intuitive over beautiful
- Accessible over trendy
- Consistent over unique
- Responsive over pixel-perfect
- Flexible over prescriptive

**In Communication:**

- Clear over comprehensive
- Actionable over theoretical
- Honest over diplomatic
- Constructive over critical