Actionaly

When Actionaly first started partnering with external vendors, every integration was effectively a custom project.Each partner required dedicated API endpoints, authentication work, backend proxying, and sometimes custom user interfaces to create a seamless experience for schools and families. While this approach worked for the first few partnerships, it created a scaling problem. Every new integration increased engineering effort, introduced custom code paths, and made us dependent on third-party systems that were not always designed for our use cases.I saw an opportunity to fundamentally change the integration model.Instead of Actionaly building custom integrations for every vendor, I proposed turning Actionaly into a platform that vendors could build upon themselves. The objective was to expose the core capabilities through standardized APIs, provide the necessary authentication and embedding mechanisms, and create a complete developer experience that would allow vendors to onboard with minimal engineering involvement from our team.I used a quiet Christmas period to build the first version of the platform. The initial release included a vendor API exposing key Actionaly resources and capabilities, allowing approved vendors to access school, class, group, user, and activity-related information through a consistent interface rather than through custom-built endpoints.To validate the concept, I also built a demonstration vendor application that showcased the integration experience from a partner’s perspective. This allowed stakeholders to understand how vendors could authenticate, access data, and build experiences on top of Actionaly without requiring bespoke engineering work.Following positive feedback, I expanded the project into a complete vendor platform.I developed a vendor dashboard where partners could manage API keys, configure OAuth and single sign-on settings, browse available resources, and manage their integration. The platform exposes entities such as schools, classes, groups, students, parents, and teachers, providing vendors with a clear and secure way to access district-approved information.One of the most technically challenging aspects was the embedded application experience. Vendors could surface parts of their own applications directly within the Actionaly administration interface through secure iframe integrations. I designed and implemented the authentication and communication flow that allowed users to move seamlessly between Actionaly and vendor applications while preserving security, identity, and tenant context.Beyond the APIs themselves, I invested heavily in developer experience. I created comprehensive documentation and step-by-step implementation guides using Docusaurus, covering authentication, resource discovery, activity creation, response retrieval, and platform capabilities. The goal was not only to document endpoints but to provide vendors with a complete onboarding path.To further reduce adoption friction, I built an interactive demo environment powered by a realistic dataset. Prospective vendors could create an account, explore resources, send activities, review responses, and experiment with platform capabilities without requiring access to a real school district. This significantly improved demonstrations, onboarding discussions, and proof-of-concept evaluations.The result was a fundamental shift in how Actionaly approached partnerships.Instead of positioning integrations as custom engineering engagements, Actionaly could now present itself as a platform that vendors could build upon through APIs, SSO, embedded experiences, and self-service tooling.This also changed the commercial narrative. The CEO could position Actionaly as a platform connecting approved vendors with school districts and families, rather than a product requiring custom development for every partnership opportunity.The platform has already contributed to securing multiple vendor customers and continues to support ongoing partnership discussions. It also enabled the delivery of a dedicated vendor-focused application for a large school district without introducing complexity into the core product.What began as an effort to reduce integration costs ultimately became a strategic platform capability that improved scalability, accelerated vendor onboarding, strengthened the company's market positioning, and created new business opportunities.Duration: Initial platform MVP built during a calm development sprint, followed by iterative expansion into a complete vendor platform over subsequent releases.Impact: Reduced reliance on custom integrations; enabled self-service vendor onboarding; improved developer experience through APIs, documentation, and tutorials; supported multiple vendor partnerships; strengthened Actionaly's platform positioning and sales narrative.Technologies used: TypeScript, NestJS, Angular, OAuth 2.0, Single Sign-On (SSO), REST APIs, iframe embedding, Docusaurus, API key management, multi-tenant platform architecture, developer portals.

Designed and built a vendor platform that transformed partner integrations from custom engineering projects into a self-service ecosystem. The platform provides APIs, SSO, embedded applications, developer tooling, documentation, and onboarding workflows, enabling third-party vendors to build on top of the Actionaly Platform capabilities while reducing engineering effort and accelerating partnership opportunities.

Product Ownership

Software Craftsmanship

Fullstack Development

Building a Vendor Platform: From Custom Integrations to a Scalable Ecosystem

At Actionaly, we wanted to explore whether we could access useful school information from Student Information System portals in situations where we did not have API access, or where the official API exposed less information than the web portal itself.The business and product question was highly exploratory: with parent-provided credentials and consent, could we reliably navigate SIS dashboards, retrieve relevant information, and automate that process across portals with very different interfaces, authentication flows, page structures, and technical behaviors?A traditional approach would have required developers to manually write a custom scraper for every portal. That would have been slow, fragile, and difficult to scale. I proposed a different approach: use an AI agent for the ambiguous exploration phase, then turn the successful navigation into a reusable deterministic routine that could run again without invoking an LLM every time.I designed and built the prototype in less than a month. The application included a React frontend served by a NestJS backend, with API endpoints to launch, monitor, and evaluate scraping jobs. The core automation ran as a long-running worker process using LangGraph and Puppeteer to control a headless Chrome browser.The user could provide a starting URL, high-level natural language instructions, credentials, and variables. The agent would then open the portal, handle authentication, explore the interface, search for the requested information, and report progress along the way.Because browser agents can be difficult to trust when they run invisibly, I made observability a central part of the product experience. I implemented live frontend monitoring with progress updates and screenshots of the headless browser state, allowing an operator to understand what the agent was doing, diagnose issues, and verify whether it was moving in the right direction.The most important design choice was that the agent was not only performing a one-off browsing session. As it navigated the portal, it captured the steps required to reproduce the workflow and generated a reusable programmatic routine. Once the agent successfully reached the goal, the routine could be tested and rerun to verify whether the same data could be collected reliably without asking the LLM to reason through the whole process again.I also added an optimization layer to reduce cost and improve scalability. The agent could inspect network requests and identify when some browser interactions could be replaced by direct HTTP calls. This helped reduce reliance on headless Chrome, making repeated runs faster, cheaper, and easier to scale.The result was a working internal R&amp;D platform that validated the feasibility of using AI agents to explore unfamiliar web portals and transform those explorations into reusable automation.The prototype helped Actionaly evaluate a complex product and technical opportunity without committing to a large manual scraping effort upfront. It demonstrated a scalable architecture pattern: use AI where ambiguity is high, then transition to deterministic routines where repeatability, cost control, and reliability matter most.Duration: delivered as a full internal prototype in less than one month Impact: validated the feasibility of AI-assisted SIS portal exploration; reduced the need for developers to manually create custom scrapers from scratch; introduced reusable routines to avoid repeated LLM usage; improved observability and debugging of browser automation jobs; explored HTTP-level optimization to reduce cost and headless browser dependency Technologies used: TypeScript, React, NestJS, LangGraph, Puppeteer, Headless Chrome

Designed and built an internal R&D prototype to evaluate whether an AI agent could navigate unfamiliar Student Information System portals, extract useful school data with user-provided credentials and consent, and convert successful explorations into reusable scraping routines. The project helped validate a scalable approach to browser automation when APIs were unavailable, incomplete, or less informative than the web portal itself.

LLMs / Large language models

AI-Powered Web Automation Agent for SIS Portal Data Extraction

At Actionaly, one of the biggest operational bottlenecks was the creation of “activities”: sophisticated digital forms and workflows used by schools to collect information, obtain parental consent, request documents, gather signatures, manage field trips, and communicate with families.Because activities were highly configurable and relied on a complex internal data model, creating them required a specialist with deep platform knowledge. This created a business dependency: new customer use cases, onboarding requests, and internal operations could be slowed down by the availability of one expert.The initial ambition was to make activity creation self-service. However, traditional visual builders still required users to understand too much of the underlying model. As generative AI became more mature, I proposed a different approach: instead of asking users to manually build activities, they could simply describe what they wanted or upload an existing form, and the system would generate a complete Actionaly activity automatically.After getting approval, I delivered the first usable version to QA in less than two weeks.I designed the solution as a multi-stage AI pipeline rather than a single LLM call. The system processed uploaded files such as PDFs, Word documents, and images through several explicit stages: content extraction, intent modeling, activity generation, validation, versioning, persistence, and enforcement. Each step exposed progress and status to the user, making the experience transparent and reducing the “black box” effect often associated with AI features.On the backend, I built a worker-based architecture using the Codex SDK to generate structured Actionaly activities according to the same rules and specifications previously applied manually by our internal specialist. To improve output quality, I implemented RAG search over more than 200 existing production activity templates. These templates were complex JSON objects, often thousands of lines long. For each generation, the system retrieved the most relevant examples and injected them into the AI agent’s context, giving it concrete implementation references in addition to formal rules.Because AI-generated output is probabilistic, I also focused heavily on user control and operational reliability. I implemented a live activity preview, version history, one-click version switching, and direct editing capabilities for specific text or visual elements. This allowed users to refine generated activities without needing to restart the process or rely on AI for every small change.I also built internal tools so non-developers could update the rule sets injected into the AI context and configure enforcement steps. These enforcement steps triggered targeted AI correction passes for areas where the model was less reliable, allowing the team to continuously improve generation quality without requiring code changes.The result was a major reduction in operational dependency. Internal teams and district administrators can now create sophisticated activities themselves, in minutes instead of hours or days. The system supports a broad range of use cases, from simple newsletters to complex consent forms, field trips, document collection workflows, and custom school forms.The first QA feedback was very positive. The initial version was delivered so quickly that QA spent more time evaluating the feature than it took to build it. Most of the feedback focused on product refinements rather than core reliability issues.The feature also became strategically important for the business. The CEO now uses the AI Activity Builder during customer demonstrations and sales discussions. Prospective customers can provide an existing form and receive an Actionaly implementation within a day, helping demonstrate the flexibility of the platform and accelerating onboarding conversations.What started as a solution to an internal operational bottleneck became both a self-service product capability and a competitive advantage in sales conversations.Duration: first usable version delivered in less than two weeks Impact: reduced activity creation time from hours or days to minutes; reduced dependency on a single internal specialist; enabled customer-facing AI-assisted activity creation; became part of sales and demo workflows Technologies used: TypeScript, NestJS, worker architecture, Codex SDK, RAG, document processing, structured JSON generation, AI validation and enforcement pipelines

Designed and built an AI-powered activity builder for Actionaly, allowing internal teams and school district administrators to generate complex forms and workflows from natural language, PDFs, Word documents, or images. The project reduced dependency on a specialized internal operator and transformed a manual process that could take hours or days into a guided AI-assisted workflow completed in minutes.

Jean-Christophe Blondeau

Full stack / AI Engineer

About me

Work experience

Actionaly

Chief Technology Officer (CTO)

VP of Engineering

BluPods, Inc.

VP of Engineering

Full Stack Developer

Freelance Developer

Developer Senior

Developer

Consolidation officer

Auditor Trainee

Accountant Trainee

Education

42 Paris

French National

ISAM-IAE Nancy

IUT Charlemagne

Lycée Saint-Sigisbert

Portfolio

Building a Vendor Platform: From Custom Integrations to a Scalable Ecosystem

Actionaly

AI-Powered Web Automation Agent for SIS Portal Data Extraction

Actionaly

AI Activity Builder — Turning Complex School Forms into Automated Workflows

Actionaly

Talents

Recruiters

About

Jean-Christophe Blondeau

Full stack / AI Engineer

About me

Work experience

.css-171onha{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;-webkit-align-items:center;-webkit-box-align:center;-ms-flex-align:center;align-items:center;gap:4px;}Actionaly

Chief Technology Officer (CTO)

VP of Engineering

BluPods, Inc.

VP of Engineering

Full Stack Developer

Freelance Developer

Developer Senior

Developer

Consolidation officer

Auditor Trainee

Accountant Trainee

Education

42 Paris

French National

ISAM-IAE Nancy

IUT Charlemagne

Lycée Saint-Sigisbert

Portfolio

Building a Vendor Platform: From Custom Integrations to a Scalable Ecosystem

Actionaly

AI-Powered Web Automation Agent for SIS Portal Data Extraction

Actionaly

AI Activity Builder — Turning Complex School Forms into Automated Workflows

Actionaly

Talents

Recruiters

About

Actionaly