Monthly recap for march 2024
We have made progress in the creation of our micro-SaaS ecosystem, focusing development on our first product dedicated to email communication. Six market segments have been identified, with interviews underway to refine functionalities. A website and newsletter have been launched to strengthen online presence. Technical development focused on Heimdall, our user and payment management platform.
Summary of work carried out in relation to strategic choices, marketing and communications
Determining potential market segments and end-users
This month we started by drawing up a list of market segments to determine which people we could help with editorial content sent by email (the RMS project).
We have listed the following 6 segments:
For growing companies: the appeal lies in discovering email marketing tools that combine simplicity, affordability, and clear added value over existing solutions often deemed complex and costly. This search is driven by the need to stand out in a competitive environment, while carefully managing limited resources. We consider our end customers to be founders, product managers and marketing and communications departments.
Real estate agencies: along with their agents and branch managers, are specifically looking for tools that enable them to segment and personalize their newsletters effectively. This requirement stems from the desire to optimize communication with their customers, in order to differentiate themselves from competing agencies. The services available are often not very specialized, suggesting an opportunity for a more tailored solution.
Content creators: including freelancers, bloggers and YouTubers, are motivated by the use of tools that support and strengthen their communities without compromising the quality of the established relationship. Their main selection criteria are ease of use, efficiency and the ability to offer added value without negatively impacting the dynamic with their audience.
The event industry: event organizers are looking for solutions that offer them great flexibility and the ability to personalize their communications. This demand is driven by the need to reflect the uniqueness and specificity of each event, underlining the importance of tools capable of adapting to a variety of contexts and requirements.
Marketing and communication agencies: digital marketers and customer account managers aim to find solutions that promise an easy transition from their current tools. Their reluctance to change is only overcome when the new solution demonstrates a substantial advantage in terms of ease of use, cost and performance over existing options.
In regulated sectors: such as healthcare and law, legal executives and compliance officers prefer solutions that guarantee security and regulatory compliance. Their openness to the adoption of new technologies is conditioned by the ability of these tools to meet strict compliance criteria, especially as we believe we need to educate them on the benefits of email-based editorial communication for such sectors.
We were interested in defining end-user profiles with whom we'd like to exchange ideas in order to identify and list key functionalities, potential drivers of our differentiation.
We continued this analysis with 3 interviews of different profiles in relation to the growth segment.
Here is a brief summary of the discussions:
- For the time being, we've been able to validate our hypotheses concerning the cost and complexity of existing solutions,
- We discovered some interesting issues, as well as some ideas for relevant functionalities that we hadn't thought of,
- We have benefited from feedback on product creation and communication, which has enriched our knowledge of the subject.
We plan to conduct several dozen interviews over the next few weeks to enrich our lists of hypotheses and identify recurring issues in order to define a bridgehead market and an end-user persona.
Bireme Lab communication preparation
During the month of March, we discreetly took out the https://bireme.io site to write blog content and create precedence for our online presence, with a few ideas for articles we're working on. We'd like to share our monthly progress, discoveries and mood posts.
We've also created our newsletter to start collecting contacts to activate by email. We plan to transform this newsletter into a waiting list once our first product is available in closed beta access.
Work related to product design and development
Creation of the payment and user management platform
Heimdall represents a common, pre-requisite foundation for all Bireme Lab services. Its role is to centralize billing management, organization, team and user profile configurations. This is all important information that we will use in each of our products.
We decided to develop Heimdall now to ensure that all our applications benefit from the same platform, thus promoting upselling and enabling us to concentrate fully on the development of business functionalities later on. Working on this part of the product in parallel with conducting interviews allows us to take the time to objectively list the key functionality to be designed for RMS, while at the same time making progress on a necessary technical prerequisite.
Product tasks completed during the month
Product focus of the month: Heimdall
Specifications: we took the time to fully specify the data models and functionalities that will be present at the launch of the first product:
- Ability to create and manage one or more organizations,
- Management of user invitations,
- Ability to create teams linked to an organization and invite users to them,
- Permission management at both team and user levels,
- Centralized payment information and billing management for all Bireme Lab products,
- Interactive onboarding for account and organization creation.
UX/UI: we have begun to format the mock-ups of all the functionalities present in Heimdall V1.
To date, we have completed webdesign work on the following sections:
User login: login page, OTP code validation,
User onboarding: step-by-step form for users to fill in the information required to configure their workspace,
Organization creation onboarding: step-by-step form for users to fill in the information required to create an organization,
Invitation page: page for accepting an invitation to join an organization.
Focus on: permissions management
In drawing up the list of functionalities required to keep our products scale, maintainable and simple in the future, we hypothesized that reworking user management to enable the creation of organizations, teams and permissions management would be a nightmare once RMS was available for use.
We therefore decided to work actively, for Heimdall V1, on creating an organization management system enabling users to create teams, invite users and configure different levels of permissions.
We established permissions at two levels:
- at team level: the administrator of an organization can create a team, and determine the permissions that team members will have "by default" within the organization,
- at user level: an organization's administrator will be able to add permissions in addition to those inherited from the configuration of the team of which the user will be a member.
In this way, an administrator who configures his teams correctly can effectively segment access rights and uses of Bireme Lab products within his organization. This means greater speed, since the invited collaborator will, by default, have the permissions configured at team level, and greater security in terms of who is entitled to do what with the company's tools.
We have also established the following rules:
- A user cannot have fewer permissions than those of the team of which he or she is a member,
- By default, each organization will have an "Admin" team that cannot be deleted: each of its members will be considered the organization's administrator and will have full permissions.
Focus on : how we write product specifications at Bireme Lab
With a history of rather techy profiles, we decided to centralize our documentation and product specifications on GitHub.
We find this a very natural way of working, thanks to the tool's native features for collaborating on writing and revisions.
For each addition or modification we create a new branch, a pull request 1 with the following information in the description :
- Name of affected product,
- List of affected features,
- Motivations :
- for the new feature, what it brings
- for the redesign, what's wrong with the current version and what does the new version bring?
- For minor changes, why do we need to update the specification?
- Brief description of the changes,
- List any doubts you have about specific points related to the product/UX/design.
- List any doubts you have about technical feasibility
In this way, each modification to the specification is subject to revision, and we keep an efficient versioning of our work, accessible at all times.
We've created a repository dedicated to writing specifications, which we've named Papyrus.
Development work
Focus tech of the month: Heimdall
Tech tasks accomplished during the month
Creation of the development environment: implementation of the technical architecture of the products.
GraphQL API creation: creation of a web server in Rust with functions for reading, processing and saving data in our databases.
Development of user authentication: integration of the external service Clerk to manage user authentication, development of product login pages.
Development of user onboarding: creation of pages enabling users to enter their information on first login
Management and centralization of error logs: implementation of an alert system to simplify the identification and handling of technical problems that users may encounter when using our products.
Focus on: our development environment
For our applications, we decided to use the following technologies:
- Rust for the back-end libraries:
- TypeScript for front-end libraries:
- Vite to compile and minify our application
- React for user interface development
- @swan-io/use-form for form management
- @swan-io/chicane for route management
- Clerk for user authentication
- gql.tada for communication with our GraphQL API
When we develop our application, we have 2 servers running in parallel:
- the back-end server serving the GraphQL API
- a server created by Vite, which transpiles our TypeScript code each time it is modified.
To avoid CORS problems, we configured Vite to create a proxy to our back-end server.
And when we package our application, the back-end server contains the static files of our front-end application and takes care of serving them.
This gives us these advantages
- we don't need to specify the URL of the back-end server in our front-end application
- we don't need to manage CORS on the back-end
- we only have one server to manage in production (so no need to synchronize the deployment of 2 servers)
Focus on: creating the GraphQL API
As explained in the previous section, we decided to create a GraphQL API for our application. This gives us both technical and organizational advantages for our team:
- communication between front-end and back-end is type-safe 2, making development smoother and avoiding oversights in the event of API modification
- creates a generic, flexible API on the product side. Allowing us to display more information without having to modify the back-end.
For the development of this API, we turned to Rust. We're aware that this is a particular choice, as Rust is a language that requires experience and doesn't have as large a community as JavaScript, especially for web development.
But Rust has a large enough ecosystem to create robust, high-performance web applications:
- Rocket makes it easy to create a web server that combines multi-threading 3 and asynchronous code to create high-performance applications,
- the use of SQLx allows us to write SQL queries that are validated at compile time, thus speeding up development by indicating syntax errors before execution. It also tells us which SQL queries to modify in the event of a data model change,
- And with Juniper we can create a GraphQL API based on the Rust typing system. So any modification in the code is automatically reflected in the GraphQL schema, which is then used by our front-end application to infer query typing.
In the end, we succeeded in creating type-safe code from our database, through our back-end server, right up to the user interface. This gives us the confidence to deploy updates quickly and without regressions.
1: short for "Pull Request". C'est une fonctionnalité pour proposer et discuter des modifications de code avant de les fusionner avec le reste du projet
2: The term type-safe refers to code written in a statically typed programming language, where data types are checked at compile time, ensuring safer code execution by preventing potential type errors.
3: Multi-threading is a programming technique that allows a program to execute several tasks or code sections in parallel on several processor cores, as if they were running at the same time. JavaScript is a single-thread language and uses a single processor core, unlike Rust.