Skip to content
All projects

synod

Software Engineer

Synod - collaboration platform for community leaders across multiple organizations

Synod-1
Status
Live
Published

The Spark

It started with a simple observation: community leaders across different organizations — chapters, clubs, and societies — were struggling to work together. They wanted to send joint newsletters, collect member data, and plan collaborative events, but the tools they had were fragmented. Newsletters went through one platform, forms through another, event planning happened over email threads and WhatsApp groups, and nobody had a clear picture of who was doing what.

I decided to build something better.

What is Synod?

Synod — named after the Greek word for "an assembly of leaders" — is a collaboration platform designed specifically for community leadership. It brings newsletters, forms, events, and transparency into one unified system, all driven by email communication.

The platform serves three types of users: a platform administrator who manages the system, organization leaders who create content and collaborate, and community members who receive newsletters and submit forms.

The Core Features

Newsletter Studio

Leaders needed to send professional, branded emails without wrestling with complex tools. I built a rich text editor with pre-built templates that render beautifully across all devices. The workflow is simple: write your content, preview it on desktop and mobile, send a test email, then publish to your entire member base with one click. The author receives a confirmation email with delivery stats, and the activity appears in the transparency log for all leaders to see.

Advanced Form Builder

Collecting member data was another pain point. Google Forms worked, but the data lived outside the platform and had to be manually imported. I built a drag-and-drop form builder with conditional logic — fields can show, hide, or become required based on previous answers. Validation is strict, especially for email addresses, because bad data helps no one. When someone submits a form, their information flows directly into the platform's member database, ready to receive newsletters.

Event Collaboration

This is where Synod gets interesting. When leaders from different organizations want to plan a joint event, they need buy-in from everyone involved. In Synod, a leader proposes an event, and the system automatically sends approval requests to all other leaders. Every leader must approve before the event is confirmed. One rejection, and the proposer is notified with the reason. When everyone approves, the entire leadership receives a confirmation email. No chasing people for responses. No ambiguity about who said yes.

Activity Logs

Transparency was a non-negotiable requirement. Every action on the platform — newsletters sent, forms created, events approved — is logged and visible to all leaders. No more "I didn't know about that" moments. Everyone sees the same timeline of activity, building accountability and trust across organizations.

The Technical Build

I built the frontend with Next.js 14, TypeScript, and Tailwind CSS, using shadcn/ui for the component library. The backend runs on C# .NET 8 with Entity Framework Core, talking to a PostgreSQL database with Redis handling caching and session management. The entire development environment is containerized with Docker, including MailHog to catch all emails locally during development — because accidentally emailing real people during testing is a mistake you only make once.

Authentication uses JWT with refresh tokens and role-based access control. Email templates are written in MJML, which compiles to responsive HTML that renders correctly across Outlook, Gmail, Apple Mail, and everything in between. The form builder stores field configurations as JSON, with validation rules evaluated at runtime. Every data-fetching component has skeleton loaders because staring at a blank screen while waiting for data is a poor user experience.

I designed the architecture with multi-tenancy in mind from the start. While the current deployment serves one community, the system is ready to support multiple independent user groups — each with their own isolated data — without major refactoring.

Challenges I Faced

Email rendering was harder than expected. What looks perfect in a browser can break completely in Outlook. MJML solved most of this, but I still had to test across multiple clients and make compromises on certain design flourishes.

The form builder's conditional logic required careful thought. A field might depend on another field's value, which might depend on a third field. I had to ensure the evaluation order was correct and that circular dependencies were impossible.

The unanimous approval workflow seemed simple until I considered edge cases. What if a leader is removed mid-approval? What if the proposer edits the event after some approvals are in? I ended up resetting approvals on any edit and handling leader removal gracefully.

What I Learned

This project taught me that real-world workflows are messier than they appear. Sitting down with community leaders and understanding how they actually work — not how I assumed they work — shaped every feature decision.

I also learned that email is underrated as an application backbone. Treating email as a first-class communication channel rather than an afterthought made the platform feel alive and responsive, even when users weren't logged in.

Most importantly, I learned the value of building for scale before you need it. Adding multi-tenancy to an existing system is painful. Designing for it from day one added maybe 15% more upfront work but saved future headaches.

What's Next

The immediate roadmap includes onboarding additional communities onto the platform, adding analytics for newsletter engagement, and integrating with calendar applications for event scheduling. Longer term, a mobile app would make the platform more accessible for leaders on the go.

Synod started as a solution to a specific problem I observed. It's become a full product that I'm proud to have built from the ground up — from database schema to production deployment, from authentication flows to email templates, from empty states to loading skeletons. Every piece of it taught me something.

Related projects

Got a system that outgrew its first design?

Let's talk