# Bonjour case study: designing project software that removes drag

URL: https://wonderful.so/blog/bonjour-case-study
Markdown URL: https://wonderful.so/blog/bonjour-case-study.md
Content type: Case study
Published: 2026-04-19
Updated: 2026-04-19
Author: Rulian at Wonderful
Asked by: Rulian
Tags: Case Study, AI, Products

## Question

Bonjour case study: designing project software that removes drag

## Answer

Bonjour came from a frustration I have had for a long time with project management software.

Most tools turn coordination into its own job. Too many screens. Too many meetings. Too many little systems built to reassure people that work is happening instead of helping the work move.

Bonjour was my attempt to push in the opposite direction.

## The Product Idea

The thesis was simple: small SaaS teams do not need more ceremony. They need a cleaner way to stay aligned, keep context, and make decisions without feeding a project management system all day.

That led to a few strong product opinions:

- one readable feed instead of scattered updates
- async-first by default
- pull-based work instead of assignment theater
- AI used for context and usefulness, not decoration
- stale work should expire instead of pretending to matter forever

## The Interesting Part

Bonjour is not interesting because it has an AI layer. It is interesting because the AI layer is narrowly shaped around a real job: making project context easier to access and act on.

That is the pattern I care about in client work too. Use AI where it reduces drag. Do not add it just to make the product sound current.

## What It Proves

Bonjour is good proof of the kind of product thinking I bring to client work. Fewer knobs. Better defaults. More respect for attention. Less tolerance for process that exists only to create the appearance of order.

If a product depends on workflow, coordination, or good defaults, this is exactly the kind of decision-making I want to bring into the build. It is the same philosophy behind my [SaaS development work](/services/saas-development) and part of why I think the [agency vs solo](/vs/agency) tradeoff matters so much for early product teams.