yeswetrust AG is an impact-investing network in Baar. It puts founders in front of investors whose thesis fits. A team decides who joins and who meets whom.
In May 2026 the network needed software. It had to work at an investor event in Portugal on 11 July. We signed on 26 May. The full scope was due on 4 July. It was delivered.
The screens below come from the demo environment. The people, companies and numbers in them are fictional.
What made it hard
- The date was fixed. The event was booked. So the demo path had to be finished first, and the rest waited for July.
- Everything is gated. A person approves each member, each introduction and each data room. Every page has to know who is asking. A mistake here leaks private data.
- The match has to be explained. An investor will ask why a founder was shown. The answer has to arrive with the score.
- The signup email had to arrive. The host blocked outgoing mail. Verification codes never left the server, so nobody could join.
- It had to be reviewed while it was still moving. Two rounds of audit, on a codebase a few weeks old, with the date already booked.
How the match works
One function on the server scores every pair. It compares an investor's thesis with a company's profile on four things.
- Sectors they share
- The funding round, against the stages the investor backs
- The country, against the regions the investor invests in
- Impact themes they share
Sectors and round count most. No overlap at all means no match, and the company stays out of the feed.
The reasons come from the same comparison. A card reads "Backs Climate and Food Systems at Seed" because those are the tags that matched. The number and the reason cannot disagree.
The tags themselves are managed by the yeswetrust team. An investor who has not filled in a thesis gets an empty tab and a prompt to finish the profile, not a page of guesses.
What shipped
- Profiles for founders, investors and companies, with documents, slides and badges the team awards
- A discovery feed, filtered by sector and badge, with a map
- Introductions, held for the team to confirm before two members are connected
- Data rooms, opened one investor at a time
- Events with RSVP, a map, and access set per event
- An admin console for approvals, requests, events and sponsors
- One layout, from phone to desktop
How we built it
- Two weeks on a prototype. A clickable app with three demo roles. The team walked every screen and settled the design before anything was real.
- The prototype became the plan. The real app was built from it, screen by screen, starting 15 June. Django and PostgreSQL, with plain HTML, CSS and JavaScript on one origin.
- Claude Design and Claude Code. The screens were drawn in Claude Design. The code was written with Claude Code. Our developers set the architecture and reviewed every change.
- Audited twice before the event. Every screen, as a guest and in each role, on desktop and on a phone. What came out was fixed, checked in the browser and shipped by the end of June.
- Email fixed. Sent over an HTTP interface instead of the blocked ports, then the domain was authenticated. The codes went from undeliverable to a perfect score on mail-tester.
- Four hundred commits between the first production commit and 10 September.
- Added since launch: live streaming on events, a media hub, sponsors, investments logged by the team, two-factor login, an audit log.
What is next
The platform is in daily use and still being built. Three things are on the table.
- Better matching. Sort the feed by score, use the whole range instead of a narrow band, and weigh a small thesis the same as a long one. Today a single shared tag can look like a perfect fit.
- Events that feel like the room. Seats can already be requested, approved and capped, and each event has its own gallery, floor plan and partners. Next comes a bespoke page per event, so a summit and a dinner do not look the same.
- Paid events with Stripe. Ticket tiers already carry real prices, but nothing is charged yet and the team still invoices by hand. Stripe would close that: pay a tier, get the seat, with the guest list staying where it is.
Terms
- The client owns everything built for it, on full payment.
- The platform runs on the client's own servers. The team operates it.
- Handover documentation is included. There is no lock-in.
Stack
- Backend. Django, Django REST Framework, PostgreSQL.
- Frontend. Plain HTML, CSS and JavaScript, served from the same origin. No build step.
- Security. Cookie sessions, rate-limited sign-in, two-factor login, an admin audit log.
- Email. Sent over an HTTP interface, with the client's domain authenticated.
- Live video. Restream, with the status cached on the server.
- Hosting. The client's own servers.
Article 032 · 18 September 2026 · 5 min read.
Reply to paolo@mont3.ch.