![](\"https://swapcard.engineering/assets/images/image-1-eff701f694f3485369c1497f74aad0e9.png\")
Hosted Buyer Programs (HBPs) have become a must-have for many B2B events, connecting prequalified buyers with relevant exhibitors to foster meaningful business relationships. In this post, we unpack the algorithms and engineering that power this crucial feature.
\n\nBeneath the smooth surface of a polished user experience lies a tough core engine. Algorithms, graphs, and optimization do the heavy lifting, with the traditional touch of let's fit this square into that circle that characterizes any carefully designed theory when it meets real-world messiness. Still with us? Great. Let's dive in!
\nIn 1962, D. Gale and L. S. Shapley [1] introduced the assignment problem, which laid the groundwork for understanding how to match two sets of agents based on preferences. The assignment problem is a fundamental combinatorial optimization problem that is still very active today, with fields of application ranging from admission control in French universities to kidney transplants programs¹.
\nHBP essentially boils down to a sophisticated assignment problem: how do we optimally match a set of buyers with relevant exhibitors for meaningful, business-driving meetings? At first glance, it seems simple—pair each buyer to suitable sellers—but the reality is much more complex.
\nUnlike textbook bipartite matching, live event scenarios introduce a mesh of interleaved constraints:
\nPhysical Scheduling is limited by time (overlaps, event duration) and space (room capacity, access rights). HBP must avoid proposing impossible meetings.
\nPractical Attendees are busy. One cannot expect people to carefully grade every single potential meeting. We're limited to a few simple choices like “must meet”, “nice to meet”, or “do not meet”. For more nuance, HBP must extrapolate preferences using minimal user input.
\nFlexibility Real-world roles are fluid: a participant may buy milk and sell cheese; another might opt for a premium upgrade; journalists might squeeze in interviews… HBP must handle a hierarchy of possibly overlapping/conflicting conditions.
\nFairness Purely optimal algorithmic solutions may inadvertently favor some, leaving others with little—HBP should nudge the system toward fair outcomes, so everyone benefits from the experience.
\nIndividually, these five facets (assignment plus the constraints) are manageable. The real challenge—and opportunity—is orchestrating all of them together, without converting your workflow into an unwieldy machine. That's why, instead of off-the-shelf modules, we designed our own custom HBP algorithm.
\nA fundamental issue of assignment is the blocking pair [5]: Consider three participants, say Alice, Bob, and Charlie, with only one possible meeting slot. Alice wants Bob, Bob wants Charlie, Charlie wants Alice.
\nWhich meeting shall we schedule?
\nSet up Alice–Bob? Bob and Charlie will “block”: Bob wants Charlie, and Charlie has no meeting. Maybe Bob–Charlie then? Now Charlie and Alice block: Charlie seeks Alice, and Alice is left alone. Try Charlie–Alice? Alice and Bob block that.
\nThe cycle highlights a simple truth: every participant views meetings differently. Focusing only on their perspective creates conflict. Instead, each meeting should have a value set by the organizer, folding in individual preferences and the broader event context into one clear score. After all, it's the organizer who orchestrates the event, so the final decision should rest here. Theoretically, this simplifies the problem [2]; practically, it allows meetings to be ranked by a single score.
\nOur scoring function is designed to synthesize all relevant signals, blending them smartly. These factors include:
\nReciprocity If Alice wants to meet Bob, and Bob reciprocates, the score goes up.
\nPriority Premium participants or sponsor status should boost meeting scores.
\nIntensity “Must meet” preferences trump mere interest.
\nAffinity A shared background increases the value.
\nWe structure signals in a precedence order: reciprocity outranks priority, which rules over intensity, which surpasses affinity. This ensures the most critical factors are always weighed first, with subtler signals retaining influence.
\nArmed with these weighted scores, meeting choices can be justified. In Alice-Bob-Charlie example above, should the organizer pick Alice–Bob and face objections from Bob and Charlie, there's a transparent rationale: perhaps Alice paid for premium priority, or flagged Bob as “must have”, or shares greater professional affinity. Maybe Charlie explicitly opted out of meeting Bob, etc.
\nA scoring function in hand, scheduling unfolds through a simple workflow.
\nMeetings ← All compatible meetings
for meeting ∈ Sorted(Meetings, decreasing)
if IsValid(meeting)
Instantiate(meeting)
Hosted Buyer Program core loop
\nStep-by-step, the process works as follows:
\nPreselect compatible meetings All conditions set by the organizer are reviewed; meetings explicitly disallowed by participants or those breaking condition options (e.g., existing contacts, colleagues) are excluded.
\nSort by decreasing scores This is where the magic happens. When we process a meeting, we know that it is more important than any meeting not processed yet, so we can fully focus on it.
\nValidate meeting Compatibility isn't enough. Schedule checks, load levels, room logistics, and dynamic issues (such as not meeting the same company twice) are all considered.
\nInstantiate the meeting Choose the best time and place for that meeting: Avoid gaps, minimize commute, prefer dedicated spaces like booths… Tag the meeting with its score, including some basic affinity details.
\nRepeat Continue until no further meetings can be placed, or participant quotas are reached.
\nPerformance is a central theme: our current system can process thousands of participants and hundreds of thousands of meeting possibilities in mere seconds.
\nSome competitors promise “perfect” solutions no matter what you throw at them, often touting terms like “AI-powered” or “machine learning-enhanced”. We promise “best-effort” solutions, grounded in good old-fashioned algorithmic principles and practical engineering².
\nAbove all, we emphasize that no algorithm can guarantee a flawless match in such a complex, constraint-laden environment. Consider for example the following scenarios, which may look trivial but are inspired by real events:
\nOne organizer wants to set up one-to-one meetings between one single buyer and multiple exhibitors. After receiving our proposal, they complain that exhibitors are mostly idle. The issue here? Unlike Schrödinger's cat, the buyer is not in a superposition of states and can only be at one place at a time. In other words: exhibitors have to wait their turn.
\nSometimes the organizer's expectations clash with physical and practical constraints, in ways that are not necessarily as obvious as in the above example. HBP keeps track of such conflicts (e.g. people, place, and time availabilities) to help the organizer understand what happened, and why.
\nQuality or quantity?
\nConsider the small one-time-slot-only HBP described in Figure 3. You have a true decision to make:
\nWe cannot stress this enough: no algorithm can magically solve such dilemmas. One must choose between quality (fewer, higher-value meetings) and quantity (more meetings, possibly of lower value). We choose quality, because it is easier to tell Alice and Diana that Bob and Charlie really want to meet than to explain Bob and Charlie that they will not meet because Alice and Diana refuse to meet.
\nThat being said, quantity has its perks too. Notably it helps fairness, ensuring more participants get at least one meeting. To balance quality and quantity, HBP incorporates a fairness heuristic through its minimum/maximum number of meetings parameters:
\nQuality prevails for a participant until they reach their minimum number of meetings.
\nQuantity takes over afterwards, favoring meetings with under-allocated participants.
\nSwapcard's Hosted Buyer Program is a smart solution to the complex challenge of matching buyers and exhibitors. Built on top of academic research, it uses a scoring system that balances organizer goals with participant preferences, ensuring fair, flexible, and high-quality meetings.
\nFor users, this means faster, more relevant matches and a smoother experience overall. HBP processes thousands of participants and meeting options in seconds, turning a complicated process into an efficient, personalized journey that helps everyone get more value from the event.
\n[1] D. Gale and L. S. Shapley, “College Admissions and the Stability of Marriage,” The American Mathematical Monthly, vol. 69, no. 1, pp. 9–15, 1962, Accessed: Sep. 05, 2025. [Online]. Available: http://www.jstor.org/stable/2312726
\n[2] F. Mathieu, “Self-stabilization in preference-based systems,” Peer-to-Peer Networking and Applications, vol. 1, no. 2, pp. 104–121, 2008, doi: 10.1007/s12083-008-0009-3.
\n[3] F. Mathieu, G. Postelnicu, and J. Reynier, “The Stable Configuration of Acyclic Preference-Based Systems,” in INFOCOM 2009, Rio de Janeiro, Brazil: IEEE, Apr. 2009, pp. 1440–1448. doi: 10.1109/INFCOM.2009.5062060.
\n[4] C. Comte, F. Mathieu, S. M. Varma, and A. Bušić, “Online Stochastic Matching: A Polytope Perspective,” Nov. 2024. [Online]. Available:https://hal.science/hal-03502084
\n[5] C.-P. Teo, J. Sethuraman, and W.-P. Tan, “Gale-Shapley Stable Marriage Problem Revisited: Strategic Issues and Applications,” Management Science, vol. 47, no. 9, pp. 1252–1267, 2001, doi:10.1287/mnsc.47.9.1252.9784.
\n¹Incidentally, my own research touches on this field ([2], [3], or [4]).
\n²And yes, before you ask: it's also “AI-powered” and “machine learning-enhanced”. But what isn't nowadays?
", "url": "https://swapcard.engineering/hosted-buyer-program-looking-under-the-hood/", "title": "Hosted Buyer Program: Looking Under the Hood", "summary": "The algorithms and engineering behind Hosted Buyer Programs: how we match prequalified buyers with the right exhibitors at B2B events.", "date_modified": "2025-11-04T17:23:29.000Z", "author": { "name": "Fabien Mathieu" }, "tags": [ "Machine learning" ] }, { "id": "https://swapcard.engineering/how-to-organize-and-grow-as-a-full-remote-engineering-team/", "content_html": "Today, more and more companies are adopting a fully remote policy. Along with the advantages come a few new challenges. Among them the one we’re going to focus in this article: how to organize a team without ever meeting them.
\nSwapcard was founded in Paris and started small with the entire team being in Paris at the time. Now, the company is more than 200 people strong, but only around 30 people still work from the Paris office. The rest of the people are scattered throughout the world. Swapcard’s culture is 100% directed at how best to integrate each and every one of its employees and they’re doing a terrific job, but it’s still up to each department to organize collaboration in their ranks.
\nThe frontend team (which I’m a happy member of) has been experimenting with various methods and processes, and this article aims at detailing how those tools are making our everyday collaboration and growth a success. I will specifically be talking about where the information exists and how it’s organized; how rules and practices are discussed and evolve; and how we enforce their usage.
\nTo achieve the processes we have, we’re using tools most companies are familiar with, I’m listing here those that will be mentioned further into the article:
\nNotion: It’s the knowledge base of the company. We use it for all kinds of company-wide information and rules such as internal rules, org charts, processes, and contacts. We also use it for local things like the Paris office’s wifi and trash sorting rules. Each department uses it for their own internal documentation, write down all of their processes, rules, meetings reports, etc. Basically, everything that anybody could have a question about at any point.
\nSlack: It’s used company-wide for both important company communication and everyday professional/personal chats. We created several channels each with a very specific purposes so no channel is cluttered and information is easily findable.
\nJira: It’s used by all the engineering department for project management. We have boards for every team but also shared ones that I will talk more about further down.
\nAgile methodology: Our project management framework doesn’t follow the SCRUM guidelines to the letter but is still very close to it. This means we have all the scrum ceremonies like daily stand-ups, sprint plannings, retrospective meetings, and others.
\nTeam organization: It is based on the Spotify model and aims to scale the agile approach and keep an innovative, creative startup vibe. The product and the tech team are organized in:
\nWhen sharing physical offices with your team you get organically onboarded by the people, day by day. Every process gets explained, observed, repeated and assisted by someone until they’re assimilated. If something changes, the transition happens the same way since everybody around us transitions to it in the same physical space.
\nWhen working remotely there is no such natural flow of information happening; so all the information needs to be written down in a centralized place and thoroughly detailed, a lot like documentation.
\nBefore our developers can even contribute to the codebase, we need them to be able to run our various apps locally. So, we created pages to detail how they should be installed, how the configuration files should be added and what they should contain. This may seem trivial but as our tools and libraries evolve, someone may add an item to an apps configuration – which would make running it fail for everybody without an up-to-date config file. So all additions are added to the documentation, and the change is notified in the appropriate Slack channel so everyone can update their setup.
\nIn our team anybody can do releases, be it in the dev, staging or prod environment. So we need to document each of those processes for each repository detailing each step to make sure no one breaks anything. Those steps also include warning about releases in Slack and giving timely status updates. This ensures everyone is aware of what’s happening at each moment so they can decide if they may proceed with their tasks or not.
\nTo help keep a good consistency in our codebases, we also have preferred ways of writing different kinds of code blocks and patterns to implement. For instance we have guidelines about how to handle fetching, rendering loading states, rendering errors, etc. We also have guidelines about how we should generate mock data, write stories (we use Storybook extensively), and how they should be reused in our tests. Those come with numerous code examples, edge cases covering, warnings and explanations about why we’re preferring what pattern.
\nThose pages, obviously, are always kept up to date as our guidelines change.
\nFinally, for all guidelines that do not fit in a broader category we have the do’s and don’ts section. There we list all preferences regarding general code styling and good practices such as syntax specifics and naming.
\nThe do’s and don’ts section is our reference in case of doubts or \"conflicts\" during discussions or PR review, and the items in it are translated into linter rules when applicable (see “enforcing the rules” section).
\n
All those guidelines ensure code written by developers from different squads will be as homogeneous as possible. It has numerous advantages: it eases PR reviews, makes getting acquainted with unfamiliar parts of the codebase way easier, and it makes sure everybody uses code that performs better and is less bug-prone.
\nNow that all this information exists we need to make it known by developers.
\nThe process of integrating a new person into the company and bringing them up to speed with the current state of the codebase and the practices is a great occasion to map all the knowledge we created earlier. Since the company grew very quickly over the course of 2020 and 2021 (+150 employees) we put in place a thorough onboarding guide for greeting each new member in the team. The guide walks them through all our documentation so they learn about our ways and know where to find information they need.
\nThis guide can also serve as a reference for existing employees to find the content they’re looking for.
\nKanban board
\nMost developer teams already use ticket-based frameworks for tracking their tasks’ statuses so we figured setting up a kanban board for tracking specific parts of the onboarding process would feel natural to most recruits. Right now we’re using it only for the environment setup, but it could be done for the rest of the onboarding too. The blocks redirect to the aforementioned pages detailing all the steps to complete – so that anybody onboarding or starting from a fresh setup can be ready in less than a day.
\n![](\"https://swapcard.engineering/assets/images/image-2-63ab4da531b840468ec9652ab9e9e4bb.png\")
At Swapcard, our developer base is divided into squads. Each squad works on topics or apps whose specifics are not discussed with other squads on a daily basis. If each squad handled their subjects independently without ever discussing them with the rest of the team, our practices and procedures would grow apart. This could result in a codebase that is complicated to maintain and conflicting approaches to PR reviews. This is why we created a weekly meeting for the entire team, called the chapter meeting.
\nI would say that those meetings are the backbone of our team’s communication and growth. They happen every week on the same day and at the same time and usually last between 45 and 90 minutes.
\nWe have a dedicated section on Notion for them, in which can be found the reports of all previous meetings, the topics discussed, the conclusions and the actions that were taken. Before each meeting a page is available in this section called “Next chapter meeting”. There, any developer can go and create a topic using the template we put in place and describe the topic in as much details as needed for everyone to understand it.
\nAll kinds of subjects can be invoked during those meetings. Examples include:
\nTopics are debated at length and in depth with references to benchmarks, studies and articles when possible to document each opinion and take the best decision for the team. We often learn something in those and end the meeting with interesting reading lists.
\nMost of the time, those discussions result in new or updated guidelines, processes or projects. If we decide to bump some packages (like Storybook, React or Next for instance) it unlocks new patterns for us to discuss. So if we bump Storybook, we’re going to create one or more do’s and don’ts items, probably refresh the documentation page about how we write code/tests/stories and finally create tickets in our shared Jira board to refactor the existing code so we always keep our codebase aligned with our rules.
\nThe shared board is a Jira board shared across the entire chapter, unlike the squad-specific ones that are private to each squad. All tickets discussed during the chapter meeting would be created there, then discussed again if needed to agree on specs. Once a ticket is ready to be assigned, people can either freely take it or request during quarter meetings to work on it. At the beginning of each quarter we usually go over the “ready tickets” backlog and try to assign them to people. This allows everyone to know which chapter subject to focus on during the months to come. As with a regular agile board, progress is tracked on the tickets and they eventually finish in the “Done” column.
\nOf course, since the shared board tickets are not directly linked to a squad, they’re not accounted for in the product roadmap and are not naturally part of future sprint backlogs.
\nTo ensure developers can continuously work on chapter tickets, the company has agreed to allocate around 15% of each sprint’s velocity to them. Because really, reducing the tech debt improves the overall developer experience, speeding up development cycles and helping reducing the introduction of new bugs.
\nSwapcard’s top management very well understood the mid and long-term benefits of continuously fighting tech debt, and strongly encourages us to take advantage of those 10%.
\nNow that we’ve made sure the rules are well-structured and accessible – and that we have a process to challenge them and make them evolve – we need to make sure people actually abide by them.
\nRight now we have apps in different repositories (although we’re currently migrating them into a monorepo), and we also have numerous separate internal packages we’re using in our different apps. In order to maintain consistency and to enforce our code style rules we created a shared lint config used everywhere in our codebase. This ensures all code from everywhere remains up to date with our evolving standards.
\n\n\nTry to enforce that at least once a day all of your pending PR reviews are pruned.
\n
PRs are very important and have at least two purposes:
\nWe’ve also taken advantage of Github’s possibility to create PR templates to enforce some of the good practices we’ve agreed upon. Those templates include various things such as our PR title being properly formatted; the PR having added or updated stories and tests to account for the code changes; and making sure the changes meet our accessibility standards. Those templates are an extension of our rules. They also make sure our guidelines are remembered and applied.
\nAdditionally, the PR template makes sure the PR creator has made their changes available on the dev environment, to ensure both QA and reviewers can test the feature. For reviewers, mandatory testing on the dev environment is highly beneficial: it helps better prevent regressions or bugs, but it also drastically increases each contributor’s product knowledge and meta skills.
\nIn order for a PR to be ready to merge, it requires the approval of at least two reviewers and must have a pass on all its pipelines. The pipelines basically test if the code is buildable – there are no typing issues, unit tests pass and e2e tests pass.
\nLast but not least, we’re using Slack channels to separate various communication contexts. We have an all-purpose channel, but also a few others dedicated to very specific usage:
\nPersonally, the biggest advantages of working in a company instead of freelancing are the people, the discussions, and the ability to grow when working with talented people. But, in a fully remote company you might not really benefit from those advantages if the communication and organization are not handled properly. Even worse, you might end-up feeling a bit lonely and isolated.
\nOur processes are obviously not perfect and we’re continuously working on improving them, but I can say that so far they’ve been bringing to the table everything I expect to find in terms of growth, thinking and discussions when working with people.
", "url": "https://swapcard.engineering/how-to-organize-and-grow-as-a-full-remote-engineering-team/", "title": "Navigating the Challenges of Organizing a Fully Remote Engineering Team", "summary": "As more companies go fully remote, organizing a team without ever meeting them presents a challenge. Strategies like effective communication, project management tools, and team-building activities can help create a productive remote team.", "date_modified": "2023-04-20T17:23:12.000Z", "author": { "name": "Ronan Guiho", "url": "https://www.linkedin.com/in/rguiho/" }, "tags": [ "Culture" ] }, { "id": "https://swapcard.engineering/create-self-adjusting-layout-for-your-video-app-with-html-css-javascript/", "content_html": "In this article, we will see how to create a self-adjusting video call app layout with HTML, CSS, and JavaScript in 5 minutes! 🚀
\n\nThe objective is to scale the layout blocks proportionally to the screen depending on the number of participants on the video call.
\nYou can either walk through the minimal setup steps below or access the codepen with the premade setup at the end of this section.
\nCreate a single wrapper element and as many child tile elements as you may need. Please note that the id and class names need to match the JavaScript that will be shown below.
\nYou can add as many .video-tile elements as you wish.
\n![](\"https://swapcard.engineering/assets/images/image-1-2d4090e6be1c70fa1b27f6e3e1cfe854.png\")
The flex-wrap is the key for this layout to work, also instead of aspect-ratio, you can set a fixed size for the elements if you wish.
\n![](\"https://swapcard.engineering/assets/images/image-2-c4fcdb22be10f797e17442596104d3e5.png\")
Using a combination of Math.ceil and Math.sqrt we can predict the desired number of elements in a row on the self-adjusting canvas. Thanks to this information, we can compute the value for each element with respect to how many elements we want to see in a single row (and subtract the gap between elements).
\n![](\"https://swapcard.engineering/assets/images/image-3-722e5f8b5d27427e977db592e2dbb265.png\")
That's it for the minimal setup, you should have a ready self-adjusting layout with the number of tiles that you specified in the HTML section.
\nI've also prepared a more advanced sandbox where you can play with a different number of tiles through input dynamically and see how the self-adjusting layout behaves in action. 😎
\n\nThat's it!
\nYou just created a self-adjusting video-app-like layout that allows you to add as many elements as you want without having to redo a specific CSS.
I hope you found it useful and easy to implement. 🤝
\nWe use this exact layout in production with our live video backstage app!
\nTo find out more about the video backstage solution at Swapcard visit https://release.swapcard.com/introducing-speaker-backstage-3yviJa
\n![](\"https://swapcard.engineering/assets/images/image-5-eb4b91bb81654d756da11cd695faf22d.png\")
There are a few things that I've learned at Swapcard over the years, sometimes the hard way, sometimes by using common sense. Always by being human.
\nI can sum it up with one simple sentence: \"it's all about balance ⚖️.\" But that's more difficult than you might think.
\n\n\nTo get the most from your engineering team, you need to make them feel connected to the company. Don't operate as a black box; explain the company's issues, share the challenges, and always be transparent.
\n
Create a career path. If you want to prevent turnover and motivate your people, you need to embrace the career path. They need to know how you are going to make the most of their potential. Whether it's an individual contributor or high-level management, they need to understand how they can grow within the company.
\nMake sure your engineering team knows that they can grow within the company. You need to find the right balance between hiring externally and promoting internally, which can be tricky. Promoting internally will help you create a core team that grows with the company. If you give your people a chance and show that you trust them, your people will follow you almost anywhere.
\nBecoming a manager is not the only way to grow as an engineer. Don't force people to become managers when that isn't the best use of their skillset. It's better to have a great individual contributor rather than a manager that doesn't like what they are doing. You want to set your people up for success, which means identifying what they do best and putting them in positions to succeed.
\nBe human. You can use a lot of methodologies in your work, but nothing replaces the human and social elements. You can solve the majority of issues by showing a willingness to listen to people and genuinely take what they say to heart. Think about the yellow rubber duck - externalizing the issue you are facing and talking it out helps to find the problem and address it. Don't sweep your problems under the carpet where they'll collect dust. Tackle them head-on.
\nWe all make decisions based on the information we have available to us at a specific moment. It's important to own up to your past decisions and be humble when you've made a mistake. You can be wrong; mistakes are how we learn and grow. It takes a strong leader to be able to recognize where they went wrong, iterate on it, and fix it.
\nAs a leader, you need to be a problem solver and believe in the company vision. You need to earn respect and legitimacy, you cannot just ask for it. You will earn it by your day-to-day actions, which you are responsible for.
\nEngineers need to use and understand the product they're working on. This seems pretty basic, but as pure engineers, we sometimes tend to forget this part. Remind yourself that you aren't just developing some engineering solution; you're developing a product. You're the backbone that solves issues or creates new needs for people and companies.
\nDon't ask people to do things that you don't even understand or have any idea about. Of course, you cannot know everything. But have a willingness to learn and to have an opinion about a product or technology, especially if you need to manage it. This goes back to my earlier point; be curious and humble and ask people to explain to you how things work. Always be willing to learn and respect the knowledge your people bring to your team.
\nSpeaking of team, don't hesitate to talk with other teams and divisions. It's easy to be protective of your people and work, but it doesn't help your engineering team if they feel separate from the rest of the company. By working together with other teams, you can solve the most significant issues and even identify problems before they happen. You will for sure discover many quick wins that you can implement to help the company operate at scale and make everyone's life easier.
\nWhen it comes to running a team, accept that things can be chaotic. Chaos management tends to help provide structure, then iterate and find the right balance between agility and processes.
\nThe perfect engineering solution doesn't exist; it's all about the pros & cons. Don't over-engineer and try to solve issues that don't exist for today's business or product. It's important to anticipate the future while also balancing current needs in order to develop something that can scale. It's not about being perfect. It's all about finding the right balance. This takes practice, but it's an important point to remember.
\nBe careful about taking on the famous quest of developing \"agnostic\" solutions. That's often pretty hard and you cannot develop something agnostic when you only implement one provider at a time. You should be able to easily switch from one provider to another, but this doesn't mean you need to develop an entire system for something that may happen in a few years.
\nThere is no bad technology (well, maybe sometimes), but ultimately it's always about solving problems. I remember how bad PHP's reputation was during my time at engineering school, even though it's actually used by a lot of successful companies and has run at scale for most of them.
\nMake sure the QA team is part of engineering and don't make them operate as an isolated entity. Continuous delivery is key, and for this, you need to accept that zero risk is a dream (it depends on the product you are working on, of course). However, keep in mind that there are plenty of technologies that can help you remain agile and limit risk (i.e. feature flags, traffic deployment, error reporting, APM, centralized logging, E2E testing, QA review, etc.)
\nSometimes you need to break things to make them better. If a policy slows you down, remove it and try to operate without it. You cannot cover 100% of the daily actions by policy and procedures. You might be able to do this if you're Google, but not when you scale and run a new business.
\nBe careful when it comes to trends regarding technology. You can read articles about how X technology is dying, and 6 months later, read another article about how this technology is spreading all over the engineering world. Stay up-to-date with the technologies that are out there, but be wary when it comes to what's trending.
\nChoose the right infrastructure tools and adapt them to your needs. Don't run Terraform and Kubernetes if you run a small business with 2 nodes. Instead, use the AWS Console, make an easy deployment pipeline with Github Actions or Gitlab, and then ECS, for example. You might not even need to use a huge cloud provider right away. You can use a dedicated server and run deployment over SSH if the business is just starting. Understand what your system needs and choose the tools best suited for it.
\nEmbrace open-source services. You can start by doing self-hosting if you need to keep costs low. Once you can afford managed services, do it.
\nDon't copy & paste organization models from famous companies because they're successful. Take inspiration from it and adapt it to your needs, culture, organization, and business. Just because it works at another company doesn't mean that it's going to work for you. All organizations are different, so be sure to embrace what makes you stand apart and put that to work for you.
\nSLA is all about trust. Don't hide issues. Customers tend to be more understanding when you inform them about an issue right away and then follow up with a detailed post-mortem. Open a public status page that you share with your clients so that they can have easy access to this information.
\nSecurity is incredibly important and should be a central consideration from day one. If you want to build a sustainable product and prevent security issues from constantly arising, you need to start training people about security and use the right tools from the beginning.
\nRun bug bounty programs, there are usually offerings geared towards startups and it can help you gain confidence in your security. You will also learn from the issues reported and can create better guidelines for your engineers.
\nOne day, you will need IT support internally, especially if you are a distributed team. Make sure that you keep this in mind because the need for IT support will arise faster than you might think. They provide help with ordering assets at scale, handling tool access, tool reviews, common IT issues, and more. Be sure to plan for this, you'll be glad that you did.
", "url": "https://swapcard.engineering/what-i-learned-over-the-years/", "title": "What I've Learned: Reflections on Life, Work, and Growth", "summary": "Maximize your engineering team's potential by fostering a sense of connection to the company, through transparency and communication of challenges and issues.", "date_modified": "2021-11-10T08:51:00.000Z", "author": { "name": "Ronan Guiho", "url": "https://www.linkedin.com/in/rguiho/" }, "tags": [ "Culture" ] } ] }