Parcha Engineering Handbook

What is Parcha?

Parcha is building Compliance AI agents that streamline onboarding and operations for fintechs and banks. Our vision is to accelerate financial innovation. By leveraging state-of-the-art AI, Parcha enables fintechs and banks to streamline customer onboarding processes and daily operations while enhancing compliance capabilities. We allow financial institutions to serve more customers efficiently, deliver superior service experiences, increase their bottom line, and achieve sustainable growth. As these technologies become seamlessly integrated into personal and corporate financial management, the industry progresses toward more incredible innovation and accessibility. This accelerated financial evolution is the future we build through our engineering work at Parcha.

This handbook outlines how we approach engineering at Parcha, guided by our four company values: Act with Urgency, Make it Dope, Build with Rigor, and Believe!

ACT WITH URGENCY

At Parcha, moving fast is core to our culture. We operate in units of days. To understand how we engrain this value in our work, look at how a week at Parcha follows a set of rituals that keep us moving like a well-oiled engine.

Our rituals

Every Monday, we kick off with weekly planning. We discuss our monthly goals and our progress towards them and examine the specific needs of each of our customers. After sharing weekend highlights and stretching over AJ’s mudical jams, we gather around our primary ticketing system—the office whiteboard—to map out every workstream, assign clear priorities, identify owners, and map dependencies. The whiteboard serves as the system of record for our operations, keeping us always accountable. We always close planning with a quick lunch from Yoyo’s (try their Indonesian beef curry).

Then, throughout the week, we do daily standups—30 minutes in the morning to discuss where we are regarding the work we committed to do. We discuss progress and blockers, go through any unplanned work (which in a startup always happens no matter how well you plan), and reprioritize when appropriate.

On Thursdays, we do Hack Night. This is our extra push when we have dinner in the office and then go the extra mile to ensure we complete our weekly priorities and everything we promised our customers. We double down and unapologetically work as late as needed to wrap up our weekly goals - though, admittedly, working late hours isn't exclusive to Hack Nights.

And we close out the week with our Friday ritual: pizza from Il Casaro in North Beach. Even as we continue wrapping up our weekly commitments, we take a moment to share a meal and acknowledge the week's efforts and accomplishments.

We will never be the bottleneck.

Customer interactions are another way acting with urgency manifests in how we work.

We don't have a customer support team because we are the support team. When a customer reaches out, Pylon sends a message to the #customer-support-issues channel (which everyone should have in their notifications). The first person to see a message from any customer acknowledges it immediately, tells the customer we're on it, and will get back to them as soon as possible.

We raise issues in our internal customer channel, ensuring they get immediate attention from the people with the most context. If it escalates, on-call steps in.

On-call is a 24/7 responsibility. On-call must always be responsive, with incident IO set up on their phones and all relevant Slack channels monitored. If on-call cannot be available, they must find a backup or let Miguel know, who's always secondary on-call. Miguel is on-call 24/7, 365 days a year. He's always available to help you, except maybe when biking through the mountains in the East Bay on Sunday mornings. If Miguel doesn't respond to your call, try AJ or another team member.

In addition, when a customer asks for a feature or improvement we deem reasonable, the completion timeline will always be days, not weeks, not months, but days. It may not be reasonable to build an entire system in days. Still, it’s always better to get something in front of them quickly and iterate than to build something for weeks in a vacuum without any feedback or perceived sense of urgency.

MAKE IT DOPE

At Parcha, "Make it Dope" is all about the craft. We don't do half-assed stuff. We're proud of what we make. Yes, we move fast, but we don't compromise quality. We ensure that what we do works, achieves its purpose, and looks dope.

We care about the craft and quality of what we do, which must be reflected in how our product looks, API, documentation, customer interactions, and website. This extends to how we talk in the company, our office environment, our swag—everything around us. We build everything in a way that makes us feel very proud of it.

This philosophy also translates to our engineering approach. Everything we build is a system—modular, testable, and designed for reusability. We don't just write code that runs; we craft robust systems and make them better every day.

One of the ways we achieve this is by building on top of abstractions and creating our own when needed. Here are some examples:

1. We don't interact directly with LLMs. Our tool interface lets us swap LLMs and easily support the newest ones. But more importantly, BaseParcha tools support evaluation, accounting, token cost economics, and resiliency. This includes using backup vendors when the main LLM is unavailable (e.g., Claude in Anthropic versus Vertex AI) and load balancing to ensure we use as much token capacity as possible. All this is free by extending the t instead of building directly on Langchain or any LLM API.
2. We've built a robust evaluation framework on top of Braintrust that we reuse across all our LLM workflows. Instead of creating new evaluation methods for each project, we leverage and extend the eval framework. It allows us to run experiments, access datasets, and generate scores using LLM judges and human evaluators. When we need functionality that doesn't exist yet, we don't create ad hoc scripts or notebooks - we extend the framework, ensuring all improvements benefit everyone in the company. The Braintrust team is very responsive and eager to help us when we identify any gaps in their platform.
3. We don't scrape and navigate websites directly. Our robust Parcha Scraper class primarily uses Browserbase (with backups), which has been highly effective for workflows on most websites. Our scrapers have unified logging, metrics, economics, and accounting measuring built-in—things we don't get if we don't use our abstractions. The Browserbase team is another one that is always eager to help. They have even built features specifically for us when needed.
4. We don't build third-party integrations ad hoc. We use the Base API class, which, coupled with API documentation, makes building third-party integration with AI a breeze. Cursor can write integrations for us in minutes, including unit tests, integration tests, monitoring, and logging. We also measure API costs and storage, which helps us be a financially mindful company. All of this ensures our third-party integrations work.

These are just some examples of the abstractions we've built. We didn't make them all at once. This has been the accumulation of work over two years using a fairly common engineering principle:

• If you need to do something once, develop it.
• If you need to do it twice, duplicating some code may still make sense, but you should consider starting to abstract.
• If you need to do it three times and don't take the time to build the abstraction, you're not doing your job.

Part of making it dope is ensuring that our codebase is a set of testable Lego blocks we can use, reuse, improve, and abuse.

BUILD WITH RIGOR

"Build with Rigor" means that we're building software used by publicly traded companies worth tens or hundreds of billions of dollars. One day, we hope to serve them all. These companies operate in a heavily regulated industry, so we must get things right.

Everything we build must be measured against appropriate data governance standards, security, privacy, and other compliance requirements. Even though we build to move fast and make things beautiful, it's also crucial that we build things the right way—robustly and with a strict governance approach. This ensures we attract, serve, and retain these highly demanding customers operating in heavily regulated environments.

Every engineer at Parcha starts their journey by taking our in-house Python secure development lifecycle training. They must understand how we build secure code. Our code is properly tested and instrumented before going to our production systems. No software is perfect, but we should avoid any avoidable mistakes. Even though we move fast, we must spend time on thorough testing.

Testing does not need to feel like a chore. The only AI-generated commits to our codebase come dependabot,  Snyk, and Tusk. We use Tusk integrated into our systems to ensure that whenever we submit a pull request, it generates unit tests that provide coverage for many scenarios, including edge cases. Of course, we write our tests where possible, but then we let it fill in the blanks. While Tusk writes the tests and suggests a commit, it's up to you to ensure that the test makes sense when you decide to incorporate it. It's your code, even if some SoTA 20-billion param LLM wrote it for you.

Speaking about AI and coding, being small (and always aspiring to stay small), we leverage AI tools across all facets of the company, and coding is no exception. Everyone has access to Claude (including ClaudeCode) and Cursor Pro. Yes, we do some vibe coding (and even bike coding). Using AI is key for us to move quickly, but it's still crucial that we do it responsibly.

At least two humans review every line of code that makes it to our main branch: the committer and a code owner. As the share of code written by machines accelerates, it's more important than ever that every engineer in the company is highly skilled at reading and reviewing code, starting with their own.

There's no such thing as "AI slop" in our codebase. It's your slop; it's your responsibility. That's why every PR you submit starts with a draft PR you go through, leave comments on, and self-review before anyone else goes through it. If someone else reviewing your code notices something highly wrong and was written by AI, "it was written by Claude" is not an excuse. It's still your code and needs to be good, even if it was generated by Cursor Agent, Claude Code, or any other tool while you were vibing.

We evaluate our LLM workflows and take them through proper model governance, including red teaming, tests for biases, testing, monitoring, and more. Every change to one of our prompts or llm inputs needs to come with a proper evaluation compared to what some products show in our golden dataset. Any negative deviation in accuracy or cost needs to be explained and approved by either Miguel or AJ before it is taken to production.

Finally, building with rigor doesn't just mean building secure code. It also means being cost-effective, especially with LLMs. We serve customers at a large scale and aim to grow to hundreds or thousands of times our current scale. A price increase of a cent per LLM call could translate into material costs as we scale. Our approach to building LLM workflows is straightforward:

• First, we make it work
• Next, we make it dope
• Then we make it cheap

—never more expensive.

BELIEVE

"Believe" is Parcha's aspirational value - the North Star that guides us when challenges arise (which is pretty much all the time). At our core, we're tackling problems that couldn't be solved until recently. The innovations we're pioneering today were impossible just a few years ago, but now they're within our reach. And given the industry's innovation rate, what feels challenging today will become routine tomorrow.

This creates both urgency and opportunity. If we don't build it, someone else inevitably will. That’s why we need always to keep an optimistic mindset, not because it’s just right, but because we're in an industry where the impossible is becoming possible every day. That’s why instead of saying, "This is not going to work," we always ask ourselves, “How are we going to make this work?”

This unwavering and sometimes irrational belief is our fuel. When in doubt, look at that yellow Believe sign on our wall and remember, as Sam yells every Monday morning after planning: "Let's go!"