The hype cycle would suggest that software development is on a fast track to being commoditized, and that senior engineers and designers are replaceable with AI / junior counterparts. First impressions with using AI app builders and agentic coding tools feel like a confirmation of this — the output is incredible. But when the natural nuance and messiness of bringing a product to market materializes, the efficacy of these tools fades into challenges. We feel strongly that *building products without experienced builders leads to bad outcomes.*

### Quality: The persistent proof of concept

We're at the point where AI can spin up fully functioning demos without much human intervention beyond a detailed spec. *But with that speed comes a drastic shift in quality, especially in the nuances and edge cases that are key to usable and delightful products.* 

Both the foundations (code and abstraction quality, security, performance) and experience (edge cases and non-happy-paths) are problematic without a human-driven feedback loop.

This is okay for a proof of concept. But we've seen teams treat these outputs as end-state product, ready to call it a day and move onto the next roadmap item. However, those edge cases, and the code foundation *are really important* - and if left unaddressed will lead to lack of adoption, churn, and loss of velocity.

### Time to market: The brick wall

At a certain point of stitching together these proof of concepts, non-technical builders relying solely on AI tooling run into an inevitable wall.

It's not rare that builders will find a market foothold with a minimally marketable product generated by AI. The edge cases are overlooked, because they are solving a real pain point. But when they learn from users, iterate onfrom those learnings, and add on more and more, they are increasing the complexity. And at a certain point, an LLM stops being effective entirely.

LLMs are, by nature, good at things that they know -- things that are statistically relevant. But anyone who's brought a complex product to market knows...it's messy. No one atomic component is that complex. It's when you glue hundreds of them together in a (hopefully) cohesive and comprehensible system, that deeper experience and human reasoning is required.

Recovering from the brick wall means focused and skilled re-work. And increasing time to market in the early days to focus on the fabric can be really painful.

### Momentum: The debt crisis

Given the hype, founders and teams are expecting to do more with less. We've seen teams staffed with junior engineers, expected to perform at senior levels. When coupled with AI, this can feel good during the period of a product's nascency, for the reasons described above. But it's a matter of time before the debt piles up.

Granted, this has always been the case. But AI is pushing out this realization / decision, due to the speed at which code can be written and the shortcuts you can take with an agent working for you. And pushing out the point of debt pay-off only makes it harder to deal with, when the time comes. 

The momentum loss of finally having to address the spaghetti on the wall is significant.

---

This isn’t an argument against using these tools, but an urging to use them wisely and in the right contexts. We’re stoked about what they unlock -

### Designers as engineers

Equipping a designer with the ability to build, iterate, and user-test an idea is powerful. Prototypes are a huge part of our design and discovery process. All of our designers have Cursor in their toolbelt, effectively eliminating the need for an engineer to be assisting with the prototype process. This tightens feedback loops, reduces cost of discovery, and allows engineering to focus on the messy bits.

### Empowering the non-technical

We've seen on many occasions non-technical folks self-serving analytics with generated SQL, effectively iterating on user-facing details of a product via code, and fleshing out their own ideas into prototypes. This is incredibly net-positive, when the outputs are integrated thoughtfully.

### Increasing engineering velocity and focus

Founding-level engineers with the ability to automate the well-defined, monotonous, and rote portions of writing code is a huge unlock, as it increases the speed (and decreases the cost) of product development, and allows for more full focus on the nuance and complexity. This requires tight feedback loops, hard-won opinions, and oversight to avoid the pitfalls above.

---

This landscape is changing so rapidly. The pitfalls will shift and shrink, and the benefits will grow as models (and feedback-loop driven tooling) improve. But we feel strongly that building products that humans want to use is, and will always be, a form of art.

giphy.gif

Building with AI unlocks a lot, but bringing a product to market without experienced humans is wrought with pitfalls.

Smooth sailing into brick walls

All of our internal (values, playbook, proposals) and external (blog posts, product + architecture specs, emails, proposals) writing is generated the old fashioned way: bashing your fingers (and sometimes head, as it feels like) across a keyboard. It's not because LLMs aren't capable, but because *writing is a fundamental form of thinking.*

Given a personal data set, well-crafted prompt, and agentic "peer review" feedback loop, LLMs can match tone and craft logical arguments exceptionally well. The process:

1. Have an idea
2. Prompt the LLM to write
3. Tune / refactor prompt
4. Copy pasta
5. Profit

While the output of this can be (jarringly) good, that’s not the point. What's missed is critical - friction. And in this case, friction drives understanding, discovery, and humility.

### Understanding

You know the feeling - you’ve just read a book, go to explain a core concept for the first time to someone, and you quickly realize that you don’t understand it as much as you thought you did. This is partly due to the [generation effect](https://en.wikipedia.org/wiki/Generation_effect), which states that work generated from your own mind is both understood and remembered better than if it's purely read from a source.

Writing is the best way to uncover gaps in your understanding of a topic. Forcing yourself to synthesize through your own words will quickly expose cracks in the facade of your grip on a subject. Feynman demonstrated this through teaching - the ability to take something complex and distill it down to it's atomic and simple components. Writing is a vehicle to teach yourself, in that same capacity.

Also important is the muscle of filtering signal from noise. Writing forces us to take multiple sources (be it literature, shower thoughts, conversations, etc.) and bundle up insight into simple, compact reasoning. This is painful, but drives deeper understanding.

### Discovery

Writing forces you to make connections between ideas that are floating around in your brain. Your lived context, thoughts, opinions, and understanding form an ecosystem where ideas can collide and form novel connections. The process of writing slows us down, probes these connections, and helps facilitate those collisions (see: [Where Good Ideas Come From](https://stevenberlinjohnson.com/where-good-ideas-come-from-763bb8957069)).

LLMs force a flow from thesis -> argument. In reality, good writing and novel ideas come from the inverse. Connecting the dots between ideas through writing can surface novel and often surprising opinions that often deviate from an original thesis.

By their nature, LLMs statistically will converge arguments to their most popular representation. This goes against the human “milleau” of outlier connections, ideas, and representations. As the majority of published writing shifts from human to AI, the human element of taste and weirdness will be what sets writing apart from the crowd.

### Humility

There's a pervasive cognitive bias where limited understanding / competence leads to an overestimation of ability ([The Dunning-Kruger Effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)). Put another way - understanding breeds humility. And humility is essential to working together as humans.

By skipping out on writing, we're collectively generating false-earned confidence.

---

AI has dizzying, industry-shifting applications - which we use extensively to help build products and companies. We're just careful to apply it to areas where friction isn't a lever. Creative reasoning and weird, novel ideas are pretty important in a world where execution is cheap.

Why we embrace the friction of writing the old fashioned way.

(We) don't use LLMs for writing

small_sandwich.webp

thumbnail_sandwich.webp

sandwich.webp

Our experience as operators and feedback we've gotten from founders over the past two years is the basis for our decisions to become capital providers.

Investment Manifesto

A product is really the output of a series of "what should I/we be focused on?" questions, asked in succession. Doing so explicitly and regularly, without the weight of bias, is critical to building things that people want (to buy).

My focus is often drawn to the path of least friction. Not necessarily the "easy" problems, but ones that:

- have solutions that are clear and tractable
- have existing momentum
- are novel / fun to solve

And sometimes (happily), these things align with what is most important to be working on. But often times, I look in the rear view mirror, and realize that I've been focused on something that *won't matter*.

Having the discipline to ask critical questions that might create friction is a battle hard-won, but incredibly important. Let's call this the path of worthwhile resistance - purposefully embracing friction to ensure that you're on the right path.

Clear solutions, existing momentum, and novelty are all focus biases that stop us from continually asking - are we on the right path?

- are we focused on the fundamental problem?
- have we learned anything recently through feedback or usage that might invalidate previous hunches?
- is what we're building turning out to be too complicated or expensive compared to the value?

For example, let’s say you’re building a calendar application. You’ve got a hunch that building a widget that utilizes an LLM to create a chat-interface for scheduling would decrease user friction. Designs are locked, engineers are stoked to play with the latest model. But as you’re talking to more and more users about it, you’re noticing that people are less enthused to be talking to a computer (than clicking a few extra buttons). Shipping the feature would be the *easier* path of focus; you’ve got momentum and internal excitement. But shipping something that doesn’t directly address the core problem is 1) going to clutter the actual value proposition, and 2) going to take focus away from furthering that actual core value. As you dig more, you feel more confidence in the decision, you reset focus and end up building a better product (faster).

It's not fun to throw work away. Especially if it's good. But if there's something more important, more in-line with vision and reality, it's good to regularly pick your head up and ask the hard question - "am I actually focused on the right thing?". A core part of Bread product culture is making product development feel more like R&D - nothing-is-sacred, fast iteration, and a constant distillation of what's most important.

thumbnail_corn.webp

corn.webp

When it comes to product focus — embrace friction.

A path of worthwhile resistance

We’ve been building marketing sites for 15 years. In the beginning, we had a few choices:

- Static HTML (upload new content via FTP)
- Drupal
- WordPress
- Dreamweaver (UI based site builder from Adobe)

The line between where design ended and development began was clear, but the feedback loop was tight. Designers created everything in pixels. Every state, every gradient, every button was an image. Responsive design wasn’t a thing. You were constrained to fixed widths and unlimited vertical space, so designs were stacked. If you wanted something positioned differently (breaking the stack), you would give it specific coordinates, and it would stay there (absolute positioning).

It didn’t take long before the emergence of interactivity and increased demands for content generation took hold of the internet. Content became less of an art and more of a commodity. It was about volume, keywords, and search engine ranking. In short, you needed a CMS (Drupal or WordPress), and if you wanted to stand out, you needed interactivity (shout out to jQuery). The web was becoming even more dynamic!

As a result, tools like Dreamweaver, a UI-based site builder, were never really worth the trouble. You simply didn’t have the flexibility needed to meet your needs. With the subsequent emergence of mobile browsing, high pixel density screens, and touch interactions, frontend development became a full-blown engineering initiative. Gone were the days when you could write some HTML and CSS and YOLO it.

For years, not much changed. WordPress emerged as the clear CMS winner. A vast library of templates became available, and developers would either build their own or adapt existing sites to meet a business’s needs.

And then a few things happened:

1.	PHP lost market share to JavaScript
2.	DOM manipulation frameworks like React emerged as the frontend frameworks of choice

As a result, fewer developers on teams wanted to work with WordPress sites. They wanted to use the same stack they were building software in, and websites now required a PhD in software development just to deploy. Your CMS might be an instance of WordPress, Contently, Ghost, etc., hosted on a separate server from your actual site. You’re now consuming their APIs with some kind of static regeneration mechanism whenever new content is published on the front end.

My sense is that this has created an even bigger gap for marketers and designers to feel connected to a site’s outcome. And perhaps most importantly, it made the process of iterating on a site’s design and content slow.

These changes reinvigorated the need for a Dreamweaver-like product that could meet the demands of teams wanting to make a brand impact but still maintain the speed that a platform like SquareSpace or Wix afforded marketers.

Webflow arrived, making all of these promises with a built-in CMS and a UI-based site builder that was fully customizable. I used Webflow for a few sites and gave up. It required all the knowledge of frontend development but felt no faster than writing code and usually required some amount of code to achieve the level of interactivity I wanted.

Then, seemingly out of nowhere, Framer, formerly a mobile application prototyping tool, pivoted into a marketing site builder.

Their biggest contributions were the incorporation of Framer Motion into their product in a mostly intuitive way, just the right amount of abstraction to make it easy for designers to latch onto, and their embrace of code components.

The product isn’t perfect, but it has meant that we now only need to staff a marketing site with a designer to achieve 90% of the outcomes we want. Occasionally, we need to write a custom component, but we warn against overbuilding a marketing site before you’ve found a fit for your product.

All of our designers are now well-versed in Framer. It lowers the cost of site development and, in my opinion, has increased the quality of the outcome without sacrificing speed.

If you’re interested in making the switch, let’s chat about how Bread can help.

large_cover.jpg

medium_cover.jpg

small_cover.jpg

thumbnail_cover.jpg

cover.jpg

A brief history of how marketing site were made, and why we're using Framer moving forward.

We’re picking Framer for our marketing sites — you should too

We work with many businesses with remote or hybrid work environments. Some teams thrive in this context, others don’t. We noticed some consistent behaviors great remote teams exhibit.

1. **They are explicit about norms, tooling, and work styles**. This is usually demonstrated by investment in great tools, intense customization of tools to fit a business’ unique context, and clarity on things like availability, documentation, and response times. They also tend to ensure all employees’ work experience is consistent in terms of hardware, decent furniture, gear, internet speed etc.

2. **They still spend significant amounts of time together in person.** This is unintuitive, but we think this is a function of founding teams being really good friends with intertwined lives, and the process of building new relationships with customers, investors and employees who often require in person time at least in the early innings. Great remote teams use these opportunities, and create opportunities like regular off-sites, to spend time together, catch up and plan while executing on critical objectives.

3. **They default to analog for critical communications.** Great remote founders still handle sensitive conversations in analog ways, either by showing up for a coffee, or at least picking up the phone and chatting through something that could be expensive emotionally or financially if misconstrued. Empathy is still, a critical part of success in any organization.

We have yet to encounter a category defining business staffed by lifestyle-first digital nomads who are 100% a-synch never connect with each other in person, have 10 different hustles, and never meet with customers or investors in person. More commonly, we see companies loosely, or inconsistently embracing some these recommended behaviors—which is just as ineffective as phoning it in.

thumbnail_phone.gif

phone.gif

We work with many businesses with remote or hybrid work environments. Some teams thrive in this context, others don’t. We noticed some consistent behaviors great remote teams exhibit.

Phoning it In

A question we often ask in first meetings with founders, partners, or potential hires is, "How do you define your values?"

We get a surprising distribution of answers, but they generally fall into three categories. The first category improvises their values on the spot. They recognize we care about this and answer in appeasement, with general aphorisms. The second category pushes back, saying either they don’t have a set of values, or don't consider them germane to the task at hand (usually in much nicer language). The third category lights up and shares insightful values they have clearly thought very deeply about.

Values don't necessarily determine the magnitude of human commercial success, but even as a small-scale startup, strongly inform the tenor of relationships and the operations of your company.

Our values are both actual and aspirational. At are best, we are:

- Endlessly curious
- Kind, open, and direct
- Too small to specialize
- Upholding quality through authenticity
- Keeping it simple
- Giving space to good ideas

### Endlessly curious

Improvement stems from curiosity. Curiosity is the approaching of hard problems not through force, but through amusement - it’s how we turn work into play. 

When presented new tools, we explore their shape, utility, and construction. We perfect their use.

We optimize for speed and quality over everything and are ready to try new tools and processes if they offer potential for improvement. If they indeed offer improved speed and quality, we transition.

### Kind, open, and direct

Integrity and trust is earned through consistent, open communication. We put ourselves on the line. We challenge each other through encouragement.

We share dissent constructively and with respect.

We keep professional conversations with each other or clients in public. We invest in tools such as Slack, Google Meet, and Notion to communicate about projects, within Bread, and publicly.

We prefer transparency of information whenever possible.

We do all of this while maintaining the privacy and confidentiality that every person deserves.

### Too small to specialize

We are not big enough to afford specialty. All of our engineers are full-stack. All of our designers are front-end developers.

We do own writing, make our own presentations, and say yes to doing things we've never done before.

### Upholding quality through authenticity

Our work is an extension of us.

We’re very rarely reinventing things. We’re in the business of refinement. We are often optimizing for time to market and process improvements over technology invention. We’re trying to help bring products into the world that are easier to use, more accessible, and more secure, using best in class tools and technology standards.

Our constraints are always time and money—we do our best work within those confines.

We are earnest and efficient with our words. If the information shared is canned, verbose, or imprecise, it will not be read.

We function through inclusivity and open-mindedness.

### Keeping it simple

It’s easy to make a mess. We are obsessive to a fault about organization and simplicity. We're fine with the trade offs. We want less garbage in our world—be it digital or physical.

Everything from your Google Drive, spreadsheets, design files, codebase, and more should be thoughtfully organized. If it’s a mess, take the time to clean it up. Your work should be beautiful, and you should be proud of it.

Simple is hard. Simple doesn’t mean bare bones, lots of white space. Simple means you put thought into organizing your work so that others can digest it easily.

Serious Face.gif

A question we always ask in first meetings with founders, partners, or potential hires is, "How do you define your values?"

Our values and why you should care about yours

## Building Software with Bread isn't for the faint of heart. You'll need to trust us with your business and we bring strong opinions to resource allocation for software development.

> Good, fast, cheap—pick two
> 

We’ve seen various shapes of this phrase over the past 15 years. We love it. Not because it’s a fundamental truth, of course decision making can be more complicated than this (morality!!), but because it’s a simple, easily applied, flexible, and thought provoking framework for resource allocation.

The best performing people we’ve worked with, whether they realize it or not, are able to assemble the right combination for their circumstance based on an accurate estimation of what is in fact good, or fast, or cheap.

If you’re a founder, executive, product owner, manager, engineer, designer, account exec etc. and your company has a mechanism for autonomy or accountability—resource allocation is really your only job.

Every situation calls for a different implementation of this framework.

---

There’s an elephant in the room:

> Move fast and break things
> 

This is a statement about resource management. People used to love it. Maybe they still do. We never did. We read it as "be fast at all cost". It's attractive when you don’t understand the repercussions of the thing you’re breaking or when learning feels more important than lighting money on fire. It can work. But I think it's missing the "good" or "cheap" directive. Moving fast can be costly (think expedited shipping) and it could mean sacrificing quality. Those two outcomes matter and there should be guidance based on what your company / market can tolerate.

---

If you work with Bread, we’re going to try to steer you in one of two directions.

As a pre-profit business (startup) your goal is to make good bets and stay alive.

As a post-profit business your trying to make big/thoughtful bets quickly.

Bread is in the business of *good* and *fast*. Good and fast win over time and apply to a business at any stage. We try to unlock “cheap” through speed, repetition and the economies of scale.

> Cheap is relative. Our economy is a figment of the [10th century imagination](https://www.independent.org/pdf/tir/tir_22_2_09_stonge.pdf). Money is pliable. Time is unrecoverable. Quality is timeless. — Me, Yesterday
> 

We recognize it’s not the only way to get things done, but it’s how we do things for two simple reasons:

1. We want to learn quickly (fast)
2. We want to test product improvements, not product parity (good)

Yes, this involves spending more early on. We prefer this to standing witness to a product's slow death.

## This is the rubric we take into every project, be it our own, or yours—it works.

### How to get good—

- Write down who your product is for
- Write down what your product is supposed to do
- Write down the performance benchmark for your market
- Build small testable versions of your product early
- Don't skip baseline requirements (e.g. user management, etc.)
- Build the baseline quickly—leverage off the shelf tools
- Focus on features that help you beat the benchmark
- Think about monetization from the start

### How to be fast—

- Choose your tools wisely
- Talk to customers after every release—create feedback loops
- Create a culture of accountability
- Take bets on resourcing and process improvements

### How to unlock cheap—

- Be realistic about your market
- Model your business
- Productize repeatable portions of process
- Remove unnecessary process or bureaucracy

## If you've done these things, you should always have a sense of how you're performing—even if you're pre-revenue.

### You know it's good is when—

- The product does the job people ask of it
- It performs faster or equal to market expectations
- How to use the product is clear to its users
- There’s a clear path to monetization

### You’re moving fast when—

- You’re releasing new or modified features every 2 - 4 weeks

### Your product is cheap if—

- Your target software margins are +100% i.e cheap to you
- Your target COGs are lower than competitors i.e. cheap to them

**This is how we measure cheap. If you want to treat software development like a commodity and measure it based on global wage rates, go for it. But the result will be a commodity product.**

Art No.gif

Aa simple, easily applied, flexible, and thought provoking framework for resource allocation.

Good, fast, cheap—pick two

We make a couple investments a year. Generally into businesses we have a working history with. 

### What we look for
1. **Ambitious teams**. On a mission to solve a large scale problem with an impactful product. A large scale problem is experienced the world over by many people. An impactful product is embraced by those people and eventually achieves a significant cumulative improvement in their lives.
2. **Unexpected Perspective**. Unique insight into an industry and problem, coupled with an uncanny ability to articulate them. It’s arresting when you hear it, as if the team sees the future.
3. **Laser Focus**. Ability to recognize distractions and avoid shiny objects. Instead choosing to focus on the fundamentals, key metrics, and core product. Knowing the quickest way to run is first crawl, then walk.
4. **Record of shipping**. Appreciating there is no such thing as a perfect product or perfect time to deploy. Having a commitment to shipping product early and often. Putting progress in user hands and iterating through customer feedback.
5. **Infectious passion**. Having a superhuman excitement for their market, product, and team. A deep conviction the world desperately needs what they're building. Along with the energy and grit to wake up and fight for it every single day.

bread.gif

We’re founders at heart. We bring that mentality to every project. Sometimes it leads to equity opportunities.  

Want a check from Bread?

No two projects are the same (see examples on our [work page](https://www.bread.works/work)). Here are our product outcomes to ensure we’re aligned and positioned for success:

### Discovery
Every project starts with discovery (i.e. research and planning). In this phase we assemble product requirements, design a collection of initial wireframes/mockups, and draft a project proposal. Think of it as a product blueprint, which you can activate with us or take elsewhere. We do discovery in 40 hour sprints, typically over 2 weeks. One sprint is enough for most projects but some may require two or more.

### Prototype
A lightweight version 1 for testing and validation. Focused on limited features. Typically scoped to a single platform (ios, android, web, etc). Ignores building for scale. And willingly accepts these parameters in favor of quickly achieving something usable. With the stated intention: put v1 in hands of early users, collect feedback, and iterate towards a production product. Prototypes can take take 2-4 months.

### Production Product
A feature enhanced, polished product that's fit for mass deployment. It has a refined interface to empower and delight your users. It’s built on a stable, extensible foundation enabling growth. It embodies your brand and takes your business to the next level. Production products can take 4-8 months.

### Long Term Partner
For teams that want a long term product partner we have a retainer model. To continually iterate and regularly ship improvements. To relentlessly improve business outcomes. Retainers are 6+ month commitments and renew on a quarterly rolling basis.

medium_Mesh Gradient Generator (8).jpeg

small_Mesh Gradient Generator (8).jpeg

thumbnail_Mesh Gradient Generator (8).jpeg

Mesh Gradient Generator (8).jpeg

Discovery, Prototypes, and Production. Learn about our recommended product phases.

Our product outcomes

We're a team of founders, designers, and engineers. After 13 years of bringing product ideas to market ([read origin story](https://www.bread.works/writing/who-we-are)), we have a strong multi-disciplinary perspective on what it takes to win:

1. **Get focused.** Poorly defined products suffer from chronic scope creep and never launch on time. We get your project scope on rails, drafting a blueprint for success before anything is built.
2. **Avoid temptations.** Skimping on the fundamentals is the product poisonous apple. We’ve made every mistake possible and refined an effective process along the way to help you avoid the land mines.
3. **Build foundations.** The surest way to slow your business is a box of spaghetti (bloated, cobbled product). We deliberately select [our stack](https://www.bread.works/work-with-us), integrations, and supporting tools to deliver you an enduring, extensible product.
4. **Prioritize time to market**. Building in isolation is a recipe for failure. We ship early and often, put product in user hands, and iterate through real world feedback.
5. **Scale on signal**. Ramping ahead of product-market fit is a good way to waste time and money. We've seen scale and know how to prepare for it, but refuse to over invest in it before warranted.
6. **Have fun**. Launching a product is hard, humbling work. The only way to succeed is to surround yourself with good, capable people, embrace the challenge, and try to have fun along the way.

medium_Mesh Gradient Generator (9).jpeg

small_Mesh Gradient Generator (9).jpeg

thumbnail_Mesh Gradient Generator (9).jpeg

Mesh Gradient Generator (9).jpeg

We like building things that people use. Here’s our best sense of how to do that. 

What makes us different

We've been building products together since 2010.

### 2010
We started Rounded, a product firm specializing in web and mobile applications. We worked with companies large and small, from private enterprise to non-profits. We helped reimagine library software for the cloud (acquired), modernize mobile tools for anglers/hunters (acquired), and launch personalized preference systems for the wine industry (active). We also tinkered with our own ideas. It was varied, exciting work allowing us to sharpen our skills and pay the bills.

### 2016
We raised venture capital for our own product, Density. Originally conceived as a side project to understand busyness of our local coffee shop. Today it’s a platform to measure and optimize commercial real estate. Over 6+ years we: raised $225m in VC, grew the team to 200, designed & deployed enterprise-grade applications, and successfully sold into F1000s. We saw and learned a lot. It was a crazy, amazing, rewarding ride. Eventually we were able to grow the company to the point that it no longer needed us. So we transitioned out to start new businesses. [Learn more about Density here](https://www.bread.works/work/density). 

### 2022
We formed Bread. A product firm to help companies design and deploy software systems. After 13 years of working together, we’ve seen it all. We’re dedicated to sharing [what we’ve learned](https://www.bread.works/writing/what-makes-us-different), so you can avoid the same mistakes.  We lean on our experience to build enduring foundations, accelerate time to market, and exceed customer expectations. We strive to solve complex problems with simple solutions. Our code is as solid as our designs. We enjoy working with (and [investing in](https://www.bread.works/writing/investments)) ambitious teams. Most of all, we’re proud to have made our careers working together and believe our background uniquely positions us to guide product ideas to market.

made
fresh
daily

Smooth sailing into brick walls

(We) don't use LLMs for writing

Investment Manifesto

A path of worthwhile resistance

We’re picking Framer for our marketing sites — you should too

Phoning it In

Our values and why you should care about yours

Good, fast, cheap—pick two

Want a check from Bread?

Our product outcomes

What makes us different

Who we are

made freshdaily

Smooth sailing into brick walls

(We) don't use LLMs for writing

Investment Manifesto

A path of worthwhile resistance

We’re picking Framer for our marketing sites — you should too

Phoning it In

Our values and why you should care about yours

Good, fast, cheap—pick two

Want a check from Bread?

Our product outcomes

What makes us different

Who we are

made
fresh
daily