Built the whole path from someone registering for a live webinar to them being a fully set up partner. Registration, a confirmation with their actual session on it, reminders down to the start, the offer link during the session, and then the account, the page and the welcome message once they sign. The part I care about is what happens to everyone who doesn't buy. A no-show gets picked up by a webhook rather than by anyone reading an attendee list, and goes into a sequence pushing the next session. Someone who turned up and didn't buy gets a different one. Nobody sits in the gap between the two.

Built the page people land on to sign up for a live webinar that runs twice a week. Almost none of it is native page-builder elements. It's hand-written and dropped in as embeds, with the page builder holding little more than the section titles. The part that took the thinking is the countdown. A session that repeats has no fixed date to count to, so the page works out its own: it reads the current time in the session's timezone, finds the next scheduled day, and targets today if you arrive before the start time or the next one if you don't. When a session begins it recalculates instead of sitting at zero. Nobody has to touch the page between sessions. Timezones are where this quietly goes wrong. My first version compared a converted time against the raw timestamp, which let the visitor's own timezone leak into the maths. The countdown was correct where the webinar is hosted and an hour off in Lisbon, nine hours off in Tokyo. It looks completely fine from the desk of whoever is testing it, which is the whole problem. The fix was to convert the same moment twice and take the difference between the two, so the viewer's offset cancels out. Daylight saving gets the same treatment: the offset is worked out when the page loads rather than written into the code, so it doesn't break six months later on a day nobody is watching. The cutoff time the countdown uses is deliberately the same one the routing automation uses to decide which session a registration belongs to. Otherwise the page counts you down to one session and signs you up to another.

Built the routing that puts registrants for a twice-weekly live webinar onto the lead pipeline. WebinarJam's registrant webhook doesn't tell you which session someone signed up for, so the automation makes a second call to the registrants endpoint to recover it, matches the person against the existing Monday board, and writes back through a GraphQL mutation built in code rather than Monday's own column-update node, which isn't reliable enough to trust. On top of that sits the scheduling rule: register before 8PM Eastern and you go to the nearer session, after it and you roll to the next one, resetting once the webinar actually starts. Anyone whose campaign tag can't be matched to a record on the board still gets added rather than quietly dropped.

Built the tracking that identifies which lead completed the purchase and signed the agreement, so onboarding can start off the back of it. The agreement has to arrive carrying that lead's Monday item ID: without it, nothing downstream can match a signature to the right record. The problem was the route it had to survive: from the offer link inside the webinar, through a Stripe checkout, through the post-payment redirect, and into the agreement form. None of those pages were mine to edit, and none of them supported dynamic URL parameters. So I built a bridge page into the middle of the chain: it captures the parameters coming off the webinar link, holds the item ID, and rewrites the outbound URL so the final page receives it intact.

Built the system behind a recurring live webinar: registration and reminders on the way in, an attendance check after each session, and then separate follow-up sequences depending on what someone actually did: never showed up, or showed up and didn't buy. It's several workflows rather than one, which is what made it complex.

Built the follow-up sequence new leads go through: eleven touchpoints across messages and emails, spread over days with waits between them so it doesn't land like an automation. Each touchpoint checks the existing thread and the board before it sends, and the path branches on whether the lead read or replied instead of firing on a timer regardless. The branching was the actual work.

Wrote a skill that holds a client's entire email house style: brand colours, type, spacing, the structural rules. Every HTML email I build for them now gets written through it, so they come out consistent without me making the same styling decisions over again on each one.

Every new lead that lands on the Monday board fires a webhook that compares its email and phone number against every lead already there, and flags it if it's a duplicate. Easy to build, but it's what stops the same person ending up in two sequences at once, or in the same one twice.

Every submission used to go through the same manual chain: download the file, find or create the right folder in Drive, upload it, create the item on the Monday board, fill in the details and who the deal belonged to, then email the file out to each lender separately, one at a time. Built the automation that does all of it: the form submission triggers the pipeline, files get routed to the correct folder, the board item is created and filled in, and distribution goes out from there. There's one manual step left on purpose: someone confirms the deal is ready before it sends. None of the individual steps were hard. The point was that all of them happened again on every single submission.

Built a tracking system for course videos hosted on Wistia and embedded in a client's Softr portal. It records, per student, how many videos they've watched, how much watch time, and what percentage of each one, and syncs it all to Monday.com. The client needed to know whether students were actually going through the material. The tricky part was hooking into the player's API from inside the embedded portal and getting reliable per-student data out of it.

Built a new student portal on Softr for a program a client was launching. The design I mostly carried over from an existing portal with a few changes. Work included: connecting it to the right Monday.com boards, embedding the course videos, restricting access so each student only sees their own data, and embedding the course resources (module PDFs) alongside the videos.

Built the full funnel behind a client's Instagram bio link: a qualification form, a video page, and a Calendly booking step. The video is locked so it can't be skipped, and the button below it unlocks progressively as the video plays, timed so it becomes clickable right when the person on screen says "click the button below." Forms built in Cognito, pages in Lovable, styled with CSS.

Built the full system design for a new program a client was launching. I took everything that had been discussed across team calls (lead capture, nurture, booking, agreements, onboarding) and mapped the complete journey in a Figma board, with the steps grouped by the automation that runs them, each group linked to its workflow. We used it in the launch-prep meeting, and it showed what still had to be built before going live. This is my favorite part of the work: thinking a process through end to end before anything gets built.

Built an automation that detects when a lead books a call and updates everything downstream: their pipeline status in Monday.com and the message sequences they're enrolled in. The detection passes each lead's ID through the Calendly link as a UTM parameter, with reliable fallbacks: if no ID comes through, it matches the booking by email or phone number, and a booking that arrives with no tracking at all gets added to the board automatically. If no match can be found anywhere, it sends a warning that the lead isn't on the leads board. Before this, a booking didn't show up in the pipeline on its own. Later rebuilt the reminder side of it too. It had been polling every five minutes to check for upcoming bookings, which meant constantly asking whether anything had changed. Now the booking event triggers the flow directly, works out when the reminder should go, and waits until then. Adding a second reminder tier after that was a config change rather than more polling logic.

Built HTML email campaigns for a client's target market: from ready-to-send templates to the n8n workflow that sent them out. Most of the work was making sure the emails actually looked right on the recipient's end, since there are a few rendering quirks to account for: videos and animations don't play in most inboxes, base64 images can get truncated. Straightforward task, but easy to get wrong if you don't know the constraints going in.

The portal runs on Softr, connected to Monday.com to pull in data. That connection broke, and it took down everything running on the portal. I went through every page and rebuilt the connections and the data restrictions of each page. Also re-embedded the client's HTML guides in the portal as part of this, which needed a different setup to display correctly.

Built a system that tracks a specific milestone in a client's contract lifecycle: the point where their customer becomes eligible for a follow-up offer. Before this, someone else could reach that customer first, costing the client money on a deal they originated. Now the system flags the date automatically, reaches out to the customer, and lets the relevant party know it's already being handled.

Part of a client's process for getting signed documents into the right place automatically. When someone signs an application, a webhook captures it, pulls the relevant info onto an internal board, and stores the signed document in a shared drive with the file linked back for easy access. That board drives the next step in the process. One click gathers everything needed and sends it out automatically. This piece is what keeps the board accurate so that step actually works. Really three or four automations working together, not one.

I build all the forms for my clients, usually with heavy conditional logic depending on what someone selects. Built in Cognito Forms, then embedded wherever the site lives (Webflow, Lovable, or a native build), and I style the HTML myself so it doesn't look like a default form bolted onto the page.

During onboarding, I found the client already had a huge number of existing automations running their whole process, with no documentation, which made the process hard for anyone to understand and turned troubleshooting into a much longer task than it should have been. To make it easier for the team, I went through everything: information from previous calls, notes I'd gathered while debugging, and worked through the full flow end to end until I understood the goal behind each piece. I mapped it all out in Mermaid.js and HTML first, then again in a Figma board to share with the team, including the link of each workflow, for easier and quicker troubleshooting when needed. From there, I did system design work to close the gaps and simplify the process, cutting the automation count down significantly.

Migrated a client's entire automation stack, over a hundred workflows, from Make and Zapier into n8n, to make everything more reliable and easier to review when troubleshooting. Went through each one and rebuilt it, improving the workflow design as I went.

Automations were spread across three platforms (Make, Zapier, and n8n), each with its own separate logs. When something broke, there was no single place to check what happened. I built a dashboard that pulled logs from all three into one place, so I could search by name or input and see which automation failed or didn't finish, instead of checking each platform separately.

I wanted to run an AI agent gateway (OpenClaw) as a personal assistant, so I set up my own VPS to self-host it. I kept the agent process alive through systemd so it survives restarts and idle logouts, and used Tailscale for encrypted remote access instead of exposing the server's SSH port to the internet. Once it was running, I had the agent build me a personal Mission Control dashboard: a single-file app to track my goals, projects, and daily tasks, with a kanban board, a timeline for longer-term plans, and notes, all saved locally. Setting the server up itself took real troubleshooting: getting a global npm install onto the system PATH, working through OAuth for model access, navigating the environment.

This was one of the first AI agents I ever built, so a year later, with a lot more experience, I rebuilt it from the ground up. I upgraded the Apify actors doing the scraping, redesigned the system to be more reliable, and focused on making the output more actionable. I also implemented a tracking system with a database to give the agent memory and context, so each run's output was tailored to what had already been done before. This is the version I later demoed publicly, selected via competitive submission as 1 of 5 demos at AI Innovation Day, Unicorn Factory Lisboa.

Not really a workflow, more of a process. My client wanted to start posting on social media but had no way to write captions that sounded like the founder. I wrote a batch of sample captions, had him react to them, and used that feedback to write every caption from then on in his actual tone of voice. It worked. Close enough that it didn't read as written by someone else. I also built out a lot of the social content and templates around this as part of setting up the posting process, even though content creation isn't really my thing.

Built Loomi as a personal project: a system that takes saved social media posts (Instagram, TikTok, YouTube) and turns them into searchable and usable items, instead of sitting in a folder forgotten. Started with just YouTube: pulled video transcripts, had an AI model extract the key points, and stored them in a database I could search. Expanded it to Instagram and TikTok, which meant handling video and images differently: video goes through one model, images and carousels through another, since each is better suited to reading that kind of content. The hardest part was building the bulk import. I built a batching system that processed them in small groups instead of all at once. After that, I added a chat feature so I could ask questions and follow up on ideas against my saved library.

Built this to track competitors' social media activity for a client's go-to-market strategy: what features they were shipping, what content was working, what people were saying about them. I set up a weekly scrape of their social media, then had an AI agent turn that into a report on what changed and what to consider, with suggestions sent straight to Slack.

Built a client's help center on Featurebase first. After running it for a few months, it stopped making sense (not flexible enough, not worth the cost), so I rebuilt the whole thing from scratch in Notion instead: docs, roadmap, changelog, all of it.

Built the recruitment system for a beta launch from scratch: no existing playbook, no user base yet. Set up a Typeform application flow with logic to sort applicants into direct access or a waitlist, wrote outreach templates for cold LinkedIn and email campaigns targeting the right audience, and built a separate recovery sequence for people who started the application but never finished it, so they didn't just disappear. Once applications came in, I reviewed and selected testers myself and handled the outreach to bring them in.

Worked with the founder to write the full onboarding series for people accepted into the beta: confirmation, download instructions for iOS and Android, orientation on what to do first, and a set of emails introducing the core features. Each one went through several rounds of rewriting to get the tone and conversion right. Also set up the domain warmup strategy for the new sending account, since it had no sending history and needed to avoid getting flagged as spam, and designed the post-beta feedback survey to collect structured input once people had used the product.

Defined the target audience for a product launch from scratch (who they were, what they cared about, how they behaved on social media), using a comparable, more established product's user base as a proxy since there wasn't one yet. Alongside that, ran a deep competitor analysis across five direct competitors: business profiles, user sentiment pulled from public comments, feature comparisons, and where the market had gaps.