[{"data":1,"prerenderedAt":436},["ShallowReactive",2],{"work-entries":3},[4,273],{"id":5,"title":6,"body":7,"description":249,"extension":250,"featured":251,"image":252,"liveUrl":253,"meta":254,"navigation":251,"order":255,"path":256,"seo":257,"sitemap":258,"stem":261,"subtitle":262,"summary":263,"tags":267,"__hash__":272},"work\u002Fwork\u002Fintegrated-email-marketing-software-with-a-saas-product-for-targeted-campaigns.md","Integrated email marketing software with a SaaS product for targeted campaigns",{"type":8,"value":9,"toc":237},"minimark",[10,21,26,29,32,37,40,44,47,50,57,61,64,67,70,73,98,101,104,107,133,136,139,142,145,148,152,212,215,218,221,225,228,231,234],[11,12,13],"blockquote",{},[14,15,16,17],"p",{},"My work at Hypefury spans several areas across growth and engineering. This case study focuses on one specific initiative: ",[18,19,20],"strong",{},"integrating Customer.io to connect product usage with lifecycle marketing.",[22,23,25],"h2",{"id":24},"overview","Overview",[14,27,28],{},"Hypefury is a social media scheduling and automation platform that helps creators publish content, grow their audience, and sell products across multiple social platforms.",[14,30,31],{},"The marketing team wanted to communicate with customers based on how they used Hypefury. However, product activity and marketing communication were disconnected. They could not easily identify customers who had never tried a particular feature, send them an educational email, or show them a relevant message while they were using the app.",[33,34,36],"h3",{"id":35},"the-challenge","The Challenge",[14,38,39],{},"The marketing team wanted to target users based on how they used Hypefury, but there was no connection between product usage and marketing. For example, if someone had never tried Auto-DMs, there was no easy way to identify them and send them an email or campaign targeted at teaching them how to use Auto-DMs, why they should use them, and so on.",[33,41,43],{"id":42},"the-solution","The Solution",[14,45,46],{},"I integrated Customer.io with Hypefury and connected every user to their activity inside the product. We sent their account information, signup source, UTM values, subscription status, and feature usage to Customer.io.",[14,48,49],{},"This allowed the email marketer to create targeted campaigns and in-app messages based on what someone had or had not done inside Hypefury, without needing an engineer every time they wanted to launch a campaign.",[14,51,52],{},[53,54],"img",{"alt":55,"src":56},"Hypefury and Customer.io integration showing user data and feature usage flowing from the app into Customer.io","https:\u002F\u002Fr2.rohitgulam.com\u002Fportfolio\u002Fwork\u002Fhypefury\u002Fhypefury-customerio-integration.svg",[22,58,60],{"id":59},"my-approach","My approach",[14,62,63],{},"I worked closely with the email marketer to understand what kind of users they wanted to target and what information they needed from the product.",[14,65,66],{},"Since I was the sole engineer on this work, I handled the data model, the backfill script, the event design, the identity fix, and the in-app messaging integration myself.",[14,68,69],{},"The first step was sending users to Customer.io. Hypefury has multiple signup flows depending on the social platform someone uses, and not all platforms give us the same information. For platforms where we received an email during signup, the user was added to Customer.io immediately. For Instagram and Threads, the next step after signup was asking the user to add their email, so we added them to Customer.io after that.",[14,71,72],{},"For each user, we sent basic account information such as:",[74,75,76,80,83,86,89,92,95],"ul",{},[77,78,79],"li",{},"Name",[77,81,82],{},"Username",[77,84,85],{},"Email",[77,87,88],{},"The platform they signed up with",[77,90,91],{},"Whether they were on a trial or paid plan",[77,93,94],{},"Subscription and account information",[77,96,97],{},"UTM values, when available",[14,99,100],{},"Hypefury already had existing users before we introduced Customer.io, so I also created a script to backfill them. I ran the backfill in batches and sent their identity and account information. Feature usage was not available at this point, so that came in the next phase.",[14,102,103],{},"After users were available in Customer.io, I started connecting their activity inside Hypefury. The email marketer told me which features and actions would be useful for creating campaigns, then I implemented the tracking inside the application.",[14,105,106],{},"Some of the information we sent included:",[74,108,109,112,115,118,121,124,127,130],{},[77,110,111],{},"How many posts someone had published",[77,113,114],{},"How many posts they had in their queue",[77,116,117],{},"How many drafts they had",[77,119,120],{},"Whether they had used AI to create posts",[77,122,123],{},"Whether they had ever used a particular feature",[77,125,126],{},"Whether they had used Auto-DMs",[77,128,129],{},"How many Auto-DMs they had sent",[77,131,132],{},"Whether they had used Auto-comments",[14,134,135],{},"Whenever one of these actions happened, we updated the relevant usage information on the user's Customer.io profile and sent the event to Customer.io. This gave the marketing team both the user's latest feature usage and the individual actions they had performed.",[14,137,138],{},"One of the technical problems I had to solve was user identification. In the first version, we used Hypefury's internal user ID as the primary identifier. This created a problem because the same person could end up with separate Customer.io profiles connected to the same email.",[14,140,141],{},"For the second version, I changed the primary identifier to email and merged the duplicate profiles. This gave us one Customer.io profile for each user and prevented their account information and feature activity from being split across multiple profiles.",[14,143,144],{},"The final part was integrating Customer.io's in-app messaging with Hypefury. Once that was working, the email marketer could create a message, choose the users they wanted to target, and display it inside the Hypefury app without needing another product release.",[14,146,147],{},"Working closely with marketing helped me decide what was worth tracking, what would actually be useful in a campaign, and what should stay out of the system.",[22,149,151],{"id":150},"outcome-and-impact","Outcome and impact",[153,154,155,168],"table",{},[156,157,158],"thead",{},[159,160,161,165],"tr",{},[162,163,164],"th",{},"Before",[162,166,167],{},"After",[169,170,171,180,188,196,204],"tbody",{},[159,172,173,177],{},[174,175,176],"td",{},"The marketing team had no reliable way to target users based on how they used Hypefury.",[174,178,179],{},"They could build campaigns around the features someone had used, had not used, or had only used a little.",[159,181,182,185],{},[174,183,184],{},"Product usage and marketing were disconnected.",[174,186,187],{},"Customer.io received account data, feature usage, and product events from inside Hypefury.",[159,189,190,193],{},[174,191,192],{},"Existing users were not available in Customer.io.",[174,194,195],{},"I migrated thousands of existing users (I can't disclose the exact number) in batches to the new Customer.io identity model without interrupting their experience.",[159,197,198,201],{},[174,199,200],{},"In-app campaigns still depended on engineering support.",[174,202,203],{},"The email marketer could create and launch targeted in-app messages without waiting for another release.",[159,205,206,209],{},[174,207,208],{},"One person could end up split across multiple Customer.io profiles.",[174,210,211],{},"I switched the primary identifier to email and merged duplicate profiles into one customer record.",[14,213,214],{},"The integration was used for onboarding, trial upgrades, product announcements, re-engagement, and teaching users about features they had not tried.",[14,216,217],{},"For example, the marketing team could identify users who had never used Auto-DMs and create a campaign specifically for them. They could do the same for Auto-comments and other features without asking an engineer to first find and export those users.",[14,219,220],{},"The biggest impact was not just that we added Customer.io. We connected the marketing team directly to what users were doing inside the product and gave them the freedom to act on that information themselves.",[22,222,224],{"id":223},"reflections-and-learning","Reflections and learning",[14,226,227],{},"The biggest lesson from this project was how important it is to choose the right user identifier before sending any data.",[14,229,230],{},"Using Hypefury's internal user ID seemed like the obvious choice at first, but it created duplicate profiles when the same person appeared under different records with the same email. Once campaigns and feature activity depend on those profiles, this becomes more than just a duplicate data problem. A user might enter the wrong campaign, receive the same message twice, or have their activity split across different profiles.",[14,232,233],{},"Changing the primary identifier to email and merging the duplicate profiles gave us a much cleaner foundation.",[14,235,236],{},"I also learned that it is not useful to track every action just because you can. I worked with the email marketer to understand what they actually wanted to do, then tracked the information that could help them do it. This made the integration useful to the people it was built for, instead of just filling Customer.io with data.",{"title":238,"searchDepth":239,"depth":239,"links":240},"",2,[241,246,247,248],{"id":24,"depth":239,"text":25,"children":242},[243,245],{"id":35,"depth":244,"text":36},3,{"id":42,"depth":244,"text":43},{"id":59,"depth":239,"text":60},{"id":150,"depth":239,"text":151},{"id":223,"depth":239,"text":224},"Integrated Customer.io with Hypefury so the marketing team could understand how customers used the product and deliver more relevant emails and in-app messages.","md",true,"https:\u002F\u002Fr2.rohitgulam.com\u002Fportfolio\u002Fwork\u002Fhypefury\u002Fhypefury-cover.png","https:\u002F\u002Fhypefury.com",{},1,"\u002Fwork\u002Fintegrated-email-marketing-software-with-a-saas-product-for-targeted-campaigns",{"title":6,"description":249},{"loc":256,"images":259},[260],{"loc":56},"work\u002Fintegrated-email-marketing-software-with-a-saas-product-for-targeted-campaigns","Hypefury",{"role":264,"client":262,"timeline":265,"team":266},"Product Engineer","Multi-phase rollout","Sole engineer, working with an email marketer",[268,269,270,271],"Product Engineering","Marketing Automation","Customer Data","Integrations","emooOufKEwm8ktERaA-iqZxK5q6SKcqddMKFvsm5RK0",{"id":274,"title":275,"body":276,"description":417,"extension":250,"featured":251,"image":418,"liveUrl":419,"meta":420,"navigation":251,"order":239,"path":421,"seo":422,"sitemap":423,"stem":426,"subtitle":427,"summary":428,"tags":431,"__hash__":435},"work\u002Fwork\u002Fturning-spreadsheet-based-operations-into-a-scalable-platform.md","Turning spreadsheet-based operations into a scalable platform",{"type":8,"value":277,"toc":408},[278,283,285,288,290,293,295,298,300,303,306,309,312,315,321,324,327,330,345,348,350,394,397,399,402,405],[11,279,280],{},[14,281,282],{},"Since this platform is used internally, there is no live link to view.",[22,284,25],{"id":24},[14,286,287],{},"EkoMobility is a Tanzanian mobility and asset financing company that helps drivers obtain motorcycles and tricycles (three-wheelers) through a rent-to-own financing model. Drivers use the vehicles to earn income while making regular daily payments toward ownership.",[33,289,36],{"id":35},[14,291,292],{},"The company ran its entire operations on Google Sheets, which worked at the beginning but quickly became painful and tedious as the company grew. More vehicles meant more drivers, which meant more payment records, and since there was no way to accept payment online, drivers had to pay via bank while staff handled manual reconciliation every day. Imagine 1,000+ daily payments being inserted manually by staff in real time.",[33,294,43],{"id":42},[14,296,297],{},"I built software that allowed them to handle their operations, including KYC, credit scoring, and payment collection, while taking into account the data they already had in Google Sheets, which was spread across 20,000+ rows in different workbooks and sheets. We also integrated with multiple payment providers, including mobile money and banks they were already using, to streamline reconciliation.",[22,299,60],{"id":59},[14,301,302],{},"Before writing a single line of code, my goal was to understand the business and how it worked offline. This involved learning the full process, from KYC for a driver, to vehicle assignment, to payments, and finally to ownership at the end of the financing term.",[14,304,305],{},"After that, I had to learn their current process in Google Sheets: how they collected data, what kind of data they collected, and how they worked together in real time.",[14,307,308],{},"This was important because they already had data, and the solution I was going to create needed to adapt to that data without being constrained in terms of scalability.",[14,310,311],{},"To do this, I worked closely with the co-founders. I did not interact much with other staff and supervisors because the co-founders already understood most of what I needed and were directly involved in day-to-day operations.",[14,313,314],{},"After understanding all this, I introduced a framework for how we would work so we could have a shared understanding: Agile Product Development.",[14,316,317],{},[53,318],{"alt":319,"src":320},"Waterfall vs Agile Product Development","https:\u002F\u002Fr2.rohitgulam.com\u002Fportfolio\u002Fwork\u002Fwaterfall-vs-agile-product-development.svg",[14,322,323],{},"We started building the software one feature at a time, end to end.",[14,325,326],{},"For example, take the KYC feature.",[14,328,329],{},"What we wanted for the feature:",[331,332,333,336,339,342],"ol",{},[77,334,335],{},"A driver form to capture the details we wanted across four different categories.",[77,337,338],{},"An assessor review of the answers.",[77,340,341],{},"Automatic score calculation.",[77,343,344],{},"The results and next steps (proceed with the driver or reject).",[14,346,347],{},"We did the same for each feature, which allowed parts of the software to become usable as they were completed.",[22,349,151],{"id":150},[153,351,352,360],{},[156,353,354],{},[159,355,356,358],{},[162,357,164],{},[162,359,167],{},[169,361,362,370,378,386],{},[159,363,364,367],{},[174,365,366],{},"Operations lived entirely in Google Sheets across 20,000+ rows spread over multiple workbooks.",[174,368,369],{},"More than 20,000 existing rows were migrated into a single system of record for KYC, credit scoring, and payments.",[159,371,372,375],{},[174,373,374],{},"Drivers could only pay via bank transfer, so every payment had to be matched to a driver by hand.",[174,376,377],{},"Payments come in through the mobile money and bank providers they already used, and the system reconciles them automatically.",[159,379,380,383],{},[174,381,382],{},"Staff manually inserted 1,000+ daily payment records in realtime, which didn't scale as the fleet grew.",[174,384,385],{},"Reconciliation happens without someone sitting at a spreadsheet all day, freeing staff to focus on drivers instead of data entry.",[159,387,388,391],{},[174,389,390],{},"KYC and credit assessment were informal, tracked wherever a sheet or a conversation left off.",[174,392,393],{},"KYC capture, assessor review, and score calculation are one connected flow with a clear accept\u002Freject outcome at the end.",[14,395,396],{},"The biggest pain point going in was reconciliation. With no online payment option, every driver payment meant a staff member cross-checking a bank statement against a spreadsheet, every day, by hand. That doesn't scale past a handful of drivers, and EkoMobility was well past that. Integrating directly with the mobile money and bank providers they already accepted payments through meant payments could match to a driver automatically instead of depending on someone catching it manually.",[22,398,224],{"id":223},[14,400,401],{},"This project was the first time I had worked directly with banks and their integrations. I initially thought it would be as simple as calling an API like Paddle, but I was wrong. There are many complications, especially when you are doing it for the first time.",[14,403,404],{},"The biggest one was VPNs. Banks do not just hand you an API key and let you start calling endpoints. Most of them require a VPN connection before their systems will even talk to you. That meant setting up VPNs to communicate with each bank, then configuring a VPN switch on my own local machine so I could actually reach those endpoints and test the integration while building, instead of only finding out something was broken once it hit a server that had access.",[14,406,407],{},"Working through those VPN requirements was a major lesson. It is one of those things you do not learn in school. You only learn it by sitting down and working through a real integration.",{"title":238,"searchDepth":239,"depth":239,"links":409},[410,414,415,416],{"id":24,"depth":239,"text":25,"children":411},[412,413],{"id":35,"depth":244,"text":36},{"id":42,"depth":244,"text":43},{"id":59,"depth":239,"text":60},{"id":150,"depth":239,"text":151},{"id":223,"depth":239,"text":224},"Replacing spreadsheet-based operations with a platform for managing drivers, vehicles, KYC, credit scoring, payments, and automatic reconciliation.","https:\u002F\u002Fr2.rohitgulam.com\u002Fportfolio\u002Fwork\u002Fekomobility\u002Fekomobility-cover-transparent.png",null,{},"\u002Fwork\u002Fturning-spreadsheet-based-operations-into-a-scalable-platform",{"title":275,"description":417},{"loc":421,"images":424},[425],{"loc":320},"work\u002Fturning-spreadsheet-based-operations-into-a-scalable-platform","EkoMobility",{"role":264,"client":427,"timeline":429,"team":430},"3 months","Solo",[432,433,434],"product engineering","payment automation","systems design","2S7ghd7jw5e4XgIq_TdKsg_7hyA_jaj3gAb4sNfZ4xE",1788452677368]