A question we always 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 altitude 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:

1. Be kind, open, and direct
2. Quality through authenticity
3. Kill the cats (be curious)
4. Keep it simple

We don't expect everyone to share all of our values, but they exist to guide us while building enduring relationships.

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 Team Values

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?

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

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 and you should too

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'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.

medium_Mesh Gradient Generator (6).jpeg

small_Mesh Gradient Generator (6).jpeg

thumbnail_Mesh Gradient Generator (6).jpeg

Mesh Gradient Generator (6).jpeg

Our origin story. It's short, we promise. 

Who we are

## 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'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

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, often it's best to embrace friction.

made
fresh
daily

Our Team Values

Want a check from Bread?

Phoning it In

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

Our product outcomes

Who we are

Good, fast, cheap—pick two

What makes us different

A path of worthwhile resistance

made freshdaily

Our Team Values

Want a check from Bread?

Phoning it In

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

Our product outcomes

Who we are

Good, fast, cheap—pick two

What makes us different

A path of worthwhile resistance

made
fresh
daily