The Croissant Collective

The Croissant Collective is a morning networking community for women in business across Sussex, and I built its digital home. The founders wanted the opposite of stuffy corporate networking: coffee, pastries, real conversation, no hard sell. My job was to make that feeling legible online and hand them a product they could run entirely themselves. So I designed and built a warm, editorial site with a live events calendar, capacity aware RSVPs with automatic waitlisting, confirmation and reminder emails, a directory of member businesses, and an admin area, so nobody ever has to ring a developer just to add an event.

Most local business networking is quietly hostile. It starts at seven in the morning, it costs a few hundred pounds a year, and in return you get a seat at a table where you are expected to deliver a sixty second pitch and produce a referral by the end of the quarter. The format rewards the confident and the extroverted, and it punishes anyone still figuring out what their business actually is. Freelancers and one person operations, who need the network most, are precisely the people who can least afford the membership fee or the obligation.

A better version is simple to describe and hard to run. It happens over coffee, at a time that fits around school runs and client calls. Nobody pitches. There is no membership, so nobody feels they have to extract value to justify the cost. The value arrives sideways: you meet three people, and six months later one of them sends you work. The founders of The Croissant Collective already knew that. What they did not have was a way to publish an event, take a name, or show a stranger that the thing existed at all.

I built this for two non-technical founders, alongside my own work. Practically, that set the boundaries.

Budget was effectively nil. Everything had to fit on free or near free tiers: a managed database, auth, storage and functions, an email provider, static hosting, and licensed stock photography. No CMS licence, no ticketing platform, no per seat tooling.

There was a chicken and egg problem. The site had to be persuasive before there was a single testimonial, attendance figure or photograph of a real event to point at. Credibility had to come from craft and clarity rather than social proof.

The founders had to be able to run it without me. If adding an event required a developer, the community would stall the first week I was busy.

Venue logistics were unsettled. There is no permanent home, so capacity changes per event, from a corner of a cafe to a private room. Capacity could not be a global setting.

And the commitment had to stay low. No accounts, no membership, no barrier between reading about an event and saying you will come.

1. I wrote a product requirements document with the founders first, covering brand palette, typography, tone of voice and a hard definition of what the first release did and did not include. Deciding what to leave out was most of the value.
2. I built a throwaway single file prototype with hardcoded events, so we could argue about the feel before I wired anything to a database. It was cheaper to disagree in a prototype than in production.
3. I shipped the marketing site with the events calendar reading live from the database, so the schedule could change without a deploy.
4. I built the admin backoffice next, before adding any more public features, because founder independence was the thing that made everything after it sustainable.
5. I replaced the planned shortcut of routing RSVPs to an external form with a proper in house RSVP system, moving capacity and waitlist logic into a database trigger.
6. I added transactional email through edge functions, so a confirmation lands immediately and a reminder lands the day before.
7. I added the business directory, giving the community something useful between events.
8. I finished with discoverability and hardening: structured data, sitemap, a file for AI crawlers, and a content security policy.

What shipped on the site:

• A landing page that reads like an invitation rather than a corporate brochure: warm off white and espresso palette, serif headings, photography of actual conversation rather than handshakes in lobbies.
• A live events grid where each card shows the venue, the time and how many spots remain, so scarcity is honest and visible rather than manufactured.
• An RSVP form inside the event modal asking for a name and email, with phone, company and message optional. The company field placeholder accepts "Just starting out", which is a small piece of copy doing a lot of emotional work.
• Capacity enforced by a database trigger rather than the browser, so two people submitting at the same moment cannot oversell a table of ten. Once full, the form quietly becomes a waitlist.
• A confirmation email on signup and a reminder the day before, both sent automatically, both escaped against injection.
• A directory of member businesses, filterable by industry tag, so referrals happen because people browse rather than because a chairperson demands one.
• An admin area where the founders create and edit events, publish or hold them as drafts, upload images, read their RSVP lists, promote people off the waitlist, and manage directory listings and tags.

• Mornings, over coffee and pastries, before the day swallows everyone.
• Deliberately small rooms, which is why capacity is per event and per venue.
• No membership and no subscription. You commit to one morning at a time.
• Price is a per event field that can be zero, so a free event and a paid workshop use the same machinery.
• The directory replaces the forced referral quota. Support is opt in and browsable rather than obligatory.

Several things I would do differently, all of them visible in the repo today.

The canonical URLs, sitemap and robots file all point at a domain that no longer resolves, while the live site sits on another. That is a real bug and it is costing search visibility. I should have made the base URL a single environment variable rather than a hardcoded constant repeated across four files.

Choosing a client rendered single page app was a mistake for this use case. Fetching the homepage as a crawler returns an empty shell, so the carefully written story and every event listing are invisible to anything that does not run JavaScript. For a site whose entire job is local discovery, I would build it statically generated next time.

There are no tests and no continuous integration. Worse, the lint command is defined but there is no lint configuration in the repo, so the command cannot actually run. That is exactly the kind of rot that sets in on a solo project with no reviewer.

Only one migration is committed. The rest of the schema lives in a dashboard, which means the database is not reproducible from source. If I lost the project I would be rebuilding from documentation.

Finally, there is no email capture. If you visit and there is no event listed yet, there is no way to say "tell me when there is one", and you are simply gone. For a community that is still building an audience, that is the most expensive omission on the list.