DEV Community: Om Rajguru

The Intuitive Interface: Moving Beyond the Static Layout

Om Rajguru — Sat, 09 May 2026 15:33:57 +0000

I want to start with a concrete picture. A growth analyst opens a dashboard every morning. She scrolls past four blocks that have nothing to do with her job to reach the one chart that runs her entire day. She has done this for two years. The app greets her like a stranger every single time. The layout is operating exactly as designed and still failing her completely.

The root problem is architectural. A fixed layout is a static assertion that every user has the same priorities. That assertion is false the moment a second user logs in. A B2B product analytics tool might have eight widgets. The developer who built it checks the API error log first. The marketing manager checks acquisition charts. The support lead checks ticket volume. The layout reflects whoever wrote the design spec. Every other user pays a small tax on every single session.

Internal tools are worse. Finance, HR, and engineering share an admin panel built for whoever made the loudest request when the panel got built. I have seen internal tools where entire sections go untouched by entire teams for months. The surface area of the product is wrong for almost everyone using it.

The same problem shows up in onboarding flows. New users land and see the full product at once. The blocks they return to tell you what their workflow actually is. The blocks they scroll past tell you what to move down. A layout that responds to those signals by session three feels faster to navigate, because it is.

Creator tools surface the clearest version of this. A writing platform with a writing editor, a distribution panel, an analytics board, and a monetization section. Most writers regularly use two of those four. The layout has no way to know which two without watching where attention actually goes.

I built a three-layer system to solve this. The first layer is a CLI tool. A CLI (command-line interface) tool is a program you run in your terminal during the build process. It scans your component tree and tags every block with a deterministic identifier derived from the file path and element position in the source. Deterministic means the identifier stays identical across re-runs and across team members. The tags survive deploys.

The second layer is a browser SDK. An SDK (software development kit) is a set of pre-written functions you import into your project. This one attaches event listeners to every tagged block and measures two things: click events and dwell time. Dwell time is how long a user's viewport overlaps with a block during an active session. The SDK sends these events to your own API route, a server endpoint you own, on your infrastructure.
The third layer is a scoring engine that runs server-side. It takes the raw engagement events and produces a score for each block per user. Recent behavior weights heavier than old behavior through a time-decay formula. The formula multiplies each event's contribution by a coefficient that shrinks as the event ages. A click from yesterday matters more than a click from three weeks ago. The engine re-ranks the block order every time the user loads the interface.

The privacy model is a first-class design decision. All event data routes through the developer's own server. There are zero third-party recipients. Deletion is built into account deletion, so when a user removes their account, their personalization data goes with it. I made that a requirement because it removes an entire class of compliance conversation.
The developer experience was the hardest thing to get right. I wanted install time under ten minutes. The system ships as three npm packages, two API routes, and no hosted backend to manage. You install the packages, wire the two routes, wrap your layout component, and the default layout serves every user who has zero history. Personalization activates on the first session and updates from there.

The identifier system deserves its own explanation because it is what makes the whole thing maintainable at team scale. Each block's ID is derived from where it lives in the source code. When a developer on your team rebuilds the project or adds a new block, every existing identifier resolves to the same value it had before. There is no migration step and no manual ID management.

A fixed layout bets that the person who wrote the spec and the person sitting in the chair share the same job. A layout that watches behavior and responds to it serves the actual person, not the imagined one. The code is small enough to read in an afternoon, runs entirely on infrastructure you already own, and the architecture is open to extend. Install instructions and the full documentation are at to.omrajguru.com/Hwp2.

I Built AdaptiveKit to Give Any Web App a UI That Learns From the People Using It

Om Rajguru — Mon, 04 May 2026 02:42:36 +0000

Most B2B web apps ship with a fixed layout. Every user who logs in sees the exact same blocks in the exact same order, whether those blocks are relevant to their workflow or completely invisible to how they actually use the product. The analytics widget that one user opens every morning sits in the same position as it does for the user who has never touched it. That felt like a solvable problem to me, and I wanted to solve it at the component level, not the content level. Most personalization tools on the market operate by swapping which data gets shown. AdaptiveKit operates by learning which UI blocks each individual user engages with most and reordering those blocks accordingly. I built it to install in under ten minutes, ship as code you own completely, and route all data through your own server with nothing leaving your stack.

AdaptiveKit is three npm packages that work together across two environments. The first package is a CLI tool, meaning a command-line program you run once from your terminal, that walks every component file in your project and attaches a stable tracking identifier to each container element it finds. A container element is an HTML tag like a div, section, article, or aside that wraps a meaningful block of content. The CLI writes these identifiers as attributes directly into your source code and records a map of every identifier back to its source component in a manifest file. The second package is a browser SDK, a small JavaScript library weighing 3 KB, that attaches to those tagged elements and watches how each user interacts with them: what they scroll past, what they click, and how long they look at something before moving on. The third package is a scoring engine that runs on your server, reads those interaction events, and produces a ranked list of block identifiers ordered by how much each individual user has engaged with each block. You apply that ranked list to your layout however your design system allows.

The CLI step is a one-time setup. You run one command, it parses every JSX and TypeScript file in your project, finds the container elements, and injects a deterministic identifier onto each one. Deterministic means the same element always generates the same identifier across different machines and across re-runs, because the identifier is derived from the file path, the component name, the element type, and its position within that component rather than from a random value. Adding new components or new elements to existing components generates new identifiers for those additions and leaves every existing identifier untouched. The only situation where existing identifiers change is when a component is renamed, which is correct behavior: a renamed component is a genuinely new component and should be treated as one. After the CLI runs, you commit the modified source files and the manifest to your repository, and those identifiers become a stable part of your codebase going forward.

The browser SDK initializes in your root layout component with two required values: the current user's ID and a callback function that fires every time an interaction event occurs. An interaction event is a data object describing one moment of engagement, containing the block identifier, the user ID, the type of interaction (a view, a click, or a dwell), and a timestamp. A dwell event fires when a user looked at a block for at least two seconds before it left their viewport, which is a stronger signal of interest than a view that registered as the user scrolled past. The callback function is where you route the event to your own server. The SDK fires it in a fire-and-forget manner so a slow network call has zero effect on the UI. The SDK uses browser APIs that are available in every modern browser, has zero external dependencies, and guards every environment-specific call so it renders safely on the server without throwing errors.

On the server side, you create two API routes. The first route receives the interaction events, loads the current user's stored scoring state from whatever database you use, feeds the new event into the scoring engine, and writes the updated state back to storage. The scoring state is a plain JSON object, meaning a straightforward data format that any database can store, containing a running score per block per user. The engine uses a decay-weighted formula to compute each score, where decay means older interactions contribute less to the final number than recent ones. A block clicked yesterday outweighs a block clicked three months ago. This keeps the ranking responsive to how a user's habits actually change over time rather than being permanently shaped by their behavior on day one. The second route reads the stored state and returns a ranked array of block identifiers, ordered from highest score to lowest, which your frontend component receives and applies to the layout.

The ranking applies to your layout through whichever mechanism your design system already supports. For a flex column layout, you set the CSS order property on each block using the position of its identifier in the ranked array, and the browser reorders the blocks visually with zero conditional rendering required. For slot-based layouts, you sort the array of blocks before rendering. For grid layouts, you use the grid-row property. AdaptiveKit takes no opinion on this step because every project's layout system is different, and the ranking is a plain array of strings that works with any approach. For users who have no interaction history yet, the engine returns an empty array, and you fall back to whatever default order your app would have shipped with before AdaptiveKit existed. The personalization activates the moment a user starts engaging, and it strengthens with every subsequent session.

I built the security and privacy model into the architecture from the first design decision. All interaction data routes through your own server. The AdaptiveKit cloud does not exist. There is no third-party recipient for any of the engagement events the SDK collects. The events contain block identifiers, user IDs, interaction types, and timestamps. They contain zero personally identifiable information, zero IP addresses, and zero content from the page. Deleting a user's personalization data requires two calls: one to reset their state inside the engine and one to delete the stored JSON from your database. That deletion path integrates directly into the same code path that deletes a user's account, which is the correct place for it. The three packages together add up to under 8 KB of browser-side code, and the server-side engine runs in any Node-compatible environment including edge runtimes and serverless functions.

I published AdaptiveKit as version 1.0 with all three packages available on npm today. The full source is on GitHub and the codebase is small enough to read in an afternoon. I built it to solve a real problem I kept running into across different products: fixed layouts that treat every user identically regardless of how differently each person actually uses the interface. The scoring engine returns results in under 5 milliseconds for a user with a thousand ingested events across fifty blocks, so the ranking adds no perceptible latency to the layout render. The roadmap includes a first-class React hook, a Vue composable, and cohort scoring for bootstrapping new users with a shared starting ranking based on how similar users behave. If you build with it, find a gap, or want to extend it, the repository is open and pull requests are welcome.

I Built a Claude Skill That Audits Your Code for Edge Cases Before They Reach Production

Om Rajguru — Fri, 01 May 2026 04:04:03 +0000

Every product I shipped had edge cases I missed. I found them the hard way: through user reports, midnight rollbacks, and refund spirals that should have been caught during review. The pattern repeated across projects: the happy path worked, but the real world found gaps I had overlooked. A phone call mid-payment. A network drop during an upload. Two tabs racing each other to submit the same form. These are the moments that define whether a product feels reliable or fragile. I kept thinking there had to be a structured way to find these failures before users did. That question became interruptions.

interruptions is a Claude skill. A Claude skill is a set of instructions and references you install into your Claude environment, and it activates when you ask Claude specific questions. Once installed, this skill triggers whenever you ask Claude to audit a flow, find what could go wrong, or stress test a feature. Claude then walks your code through 12 structured categories of failure modes, writes a comprehensive audit report to a Markdown file called interruptions-audit.md, and waits for you to read it and confirm before touching anything. After you confirm, Claude helps you fix each issue in order of severity. The installation takes one command: npx skills add omrajguru05/interruptions. From that point, the skill is available across Claude Code, Claude Desktop, and Claude.ai.

The 12 categories exist because failure modes cluster into recognizable patterns. I pulled these patterns from years of shipping and watching the same classes of bugs appear across different products and teams. UX and user psychology covers how users behave irrationally, accidentally, or in ways your design overlooked. Security covers replay attacks, insecure direct object references, frontend tampering, and weak authentication. An insecure direct object reference happens when a user can guess or modify a URL parameter to access data that belongs to another user. Design and visual state covers how the UI communicates, or fails to communicate, what happened after an action. System flow and logic design covers breakdowns in workflow sequencing and state transitions.

The remaining categories go deeper into the infrastructure and data layers. State and data integrity covers situations where the frontend, backend, and cache hold different versions of the same truth at the same time. Network and infrastructure covers timeouts, lost responses, and partial requests that leave the system in an ambiguous state. Concurrency and race conditions covers two operations happening simultaneously and producing a result that neither operation intended in isolation. Payment and transaction integrity covers the class of errors where money is involved and the cost of a mistake is real. Device and environment covers actual behavior differences across operating systems, browsers, and screen sizes that synthetic testing often overlooks. Synthetic testing means running automated scripts against your code in a controlled environment, which produces different results from a real user on a real device with a slow connection and five background tabs open.

The final three categories address the boundaries of your inputs and your error paths. Accessibility and inclusion covers screen reader compatibility, keyboard navigation, right-to-left language support, zoom behavior, and color contrast ratios. Data validation and input handling covers malformed, extreme, or intentionally hostile input that reaches your backend. Error handling and recovery covers what happens after a failure and whether a user has a path forward, or is left with a generic toast message and a phone call to support. Each category has its own set of questions, red flags, and example fixes stored inside a references file that Claude loads during the audit. These references come from real production failures observed across multiple product types and team sizes. The checklist in references/checklist.md is the canonical source the skill reads from during each audit run. It is also the file where community contributions make the biggest difference.

When you trigger the skill, the audit phase runs first. Claude greets you, asks which flow or file you want audited, and then walks the 12 categories against your code one by one. The output is a structured audit written to interruptions-audit.md, a Markdown file that lives in your project directory. Each finding in that file includes a severity rating, a file and line reference pointing to the exact location in your code, and a concrete fix with enough context to understand the change. Severity ratings follow a consistent scale so you can prioritize what to address first. The audit covers every category regardless of which flow you asked about, because failures in one area often trace back to a gap in another. After the audit is complete, the skill pauses and waits for you to read it.

This waiting behavior is intentional and the most important design decision in the entire skill. Edge case fixes touch payment paths, authentication logic, and state machines. A state machine is a structure that tracks every possible state your application can be in, and which transitions between those states are valid. If Claude starts implementing changes before you read the audit, you lose the understanding of why each change is being made. So the skill holds at step four and asks you to read the audit and confirm in plain words before a single fix is applied. This confirmation gate is the difference between a tool that helps you ship better code and one that rewrites your codebase in ways you have to reverse engineer afterward. You stay in control of what gets changed and when.

The fix phase runs under a strict set of safety rules I designed to prevent the skill from creating problems while solving them. Before any fix is applied, the skill checks that you are on a working branch, inventories your test, typecheck, and lint commands, and glances at your CI configuration to flag branches that auto-deploy to production. CI, which stands for continuous integration, is an automated system that runs your tests and checks whenever you push code. For each individual fix, the skill produces the smallest possible diff. A diff is a record of exactly which lines changed in a file and how they changed. The skill touches the function in question and its direct callers, shows you the planned change before applying it on high-risk paths, and runs your test suite after each edit. When a fix causes an existing test to fail, the skill stops entirely rather than rewriting the test to make the failure disappear.

The project accepts contributions, and the contribution bar is high by design. The edge case checklist is a production tool, and the quality of its output depends on the quality of what goes into it. You can add new edge case scenarios across any of the 12 categories, improve clarity on existing ones, or propose an entirely new category if you find a recurring failure pattern that the current structure misses. Every contribution needs three things: a concrete scenario describing the failure, an impact section describing what goes wrong for the user or the system, and a suggested safeguard describing how to prevent or handle the failure. Vague descriptions belong outside the checklist. Specific, reproducible failure paths belong inside it. The process is: fork the repository, create a branch, make your changes, and submit a pull request with a clear explanation of what you changed and why it improves the project.

I built interruptions because one person holding 12 failure categories in their head simultaneously on a focused review day is asking for a lot. A structured checklist handed to Claude and run against every flow is more reliable than memory and more thorough than a code review written by someone who already knows what they built. The skill surfaces what you missed, writes it down clearly, waits for your understanding, and then helps you address each finding in the order that matters. The fix phase runs one change at a time, with test verification after each one, so you see the impact of each individual change before the next one starts. The repository lives at github.com/omrajguru05/interruptions, and I write about the build process at omrajguru.com/devnotes/interruptions. If you run this on a flow and it surfaces something you would have shipped into production, that is the skill doing exactly what it was built to do.

How to stop Claude from scanning your entire codebase every session

Om Rajguru — Wed, 29 Apr 2026 13:43:25 +0000

If you use Claude or Cursor on a real project, you have probably hit the point where it starts reading every file just to understand what the codebase looks like. It is not doing anything wrong. It just has no other way to get context. So it scans, and that scan costs tokens every single session.

I wrote about WebDNA a while back. The short version is that it is a Next.js plugin that generates a JSON file at build time describing your routes, components, API endpoints, and brand tokens. AI agents read that file first instead of crawling your source.

Since the first post I have added a two-tier manifest system so you can exclude private routes and sensitive components from what the AI sees, a fallback API route at /api/webdna for agents that cannot access .well-known directories, and a linter that catches missing descriptions and undeclared auth scopes before they become a problem.

If you want to try it on your project, the full setup guide is at webdna.omraj.guru. It takes about five minutes and works with any Next.js project using App Router or Pages Router.

The Persistence of Intent

Om Rajguru — Wed, 29 Apr 2026 13:41:26 +0000

Imagine you have spent several minutes refining a complex dashboard. You have set the date ranges, toggled the specific filters, and drilled down into the exact data points that tell your story. You copy the link from your browser address bar and send it to a colleague to show them what you found. When they click that link, they see a blank slate. The filters are gone. The context is lost. You realize that your application only existed in that specific moment on your specific screen.

Now consider the person using your app while moving through a city. They fill out a detailed form, providing thoughtful input. They tap the button to submit their work just as their device loses its connection to the network. Instead of the data being preserved, it simply vanishes. A generic notification tells them to try again later. These are not just minor inconveniences. They are moments where the technology fails to respect the time and effort the user has invested.

We have reached a point where we treat these issues as expected behaviors. Developers spend hours writing repetitive logic to synchronize the interface with the URL or to manage the fragile state of a network request. We write the same lines of code for every new project, trying to bridge the gap between what the user sees and what the system remembers. We have inadvertently accepted that application state is a fleeting thing that lives and dies in temporary memory.

The URL is one of the most fundamental structures of the web. It was designed to be a permanent reference to a specific resource. Yet in many modern applications, the URL has become an afterthought. We allow important navigation and filter states to exist only in the memory of the current session. When a user interacts with the back button or refreshes their browser, the interface breaks because we stopped treating the URL as a reliable source of truth.

The challenge of working offline is often treated with the same lack of permanence. Most tools assume a perfect, constant connection to the internet. When that connection falters, the application stops functioning. We have grown accustomed to building software for ideal conditions, testing our work on high speed networks while our users navigate a world of tunnels, basements, and rural gaps. We lack a standard way to ensure that a user’s data is safe regardless of their signal strength.

These two problems are usually treated as separate technical hurdles. One is seen as a routing issue and the other as a data synchronization issue. Because they are handled by different tools and different libraries, they never communicate. We continue to build fragmented systems where the user’s intent is easily lost between the layers. We have not yet unified the way an application understands where it is and what it is holding.

A better experience is possible. It is an experience where you define your data once and the system handles the rest. In this environment, every meaningful change in the interface is automatically reflected in the URL, making every state shareable and persistent. In this environment, the application is inherently resilient. It waits for the network to return and ensures that no piece of information is ever discarded. The developer does not write complex synchronization logic because the system is designed to be stable by default.

This is a difficult problem to solve correctly. It requires a fundamental shift in how we think about the relationship between the user, the browser, and the server. We have been exploring a way to make this level of persistence feel natural and effortless for everyone involved. We are building a foundation that treats user intent as something that should never be lost. If these challenges represent the friction you feel in your daily work, there is more to discuss soon. Something new is being prepared.

WebDNA: A structured interface for AI agents

Om Rajguru — Mon, 06 Apr 2026 13:01:37 +0000

When I watch an AI agent or a coding tool interact with a website today, the process feels inefficient. These models are essentially forced to squint at raw HTML and minified JavaScript bundles while attempting to reverse-engineer the original intent of the developer. They miss the relationship between components, they lose the nuances of brand colors, and they struggle to understand the shape of underlying APIs. I built WebDNA to solve this by creating a bridge between the way humans write code and the way machines need to consume it.

The core idea is a manifest that lives at a predictable location on your server. By integrating directly into the Next.js build process, WebDNA automatically scans your project and generates a blueprint of your site. It looks at your route tree, extracts design tokens from your Tailwind configuration, and maps out your component hierarchy. This happens without requiring any manual documentation from the developer. It turns the implicit knowledge stored in your codebase into an explicit, structured briefing for any AI that visits your site.

This system moves beyond existing solutions like sitemaps or basic text files. While those tools offer a list of URLs or high-level summaries, they do not explain the design system or the specific data requirements of a dynamic route. WebDNA provides that missing context. It allows a developer to define which parts of a site are private and which components serve specific roles, ensuring that when an AI tool accesses the site, it does so with a full understanding of the constraints and the brand guidelines.

Security and privacy are foundational to this standard. The manifest is a static JSON file that cannot execute code and is read-only by design. I have included features like element-level exclusion, where a simple attribute can hide specific sections of a page from the AI manifest. This ensures that developers remain in total control of what information is shared. It is about providing consent-based, structured access rather than leaving AI tools to scrape whatever they can find.

My goal with WebDNA is to make the web more accessible to the next generation of software tools. By making the architecture of a site discoverable, we reduce the friction and errors that occur when AI tries to navigate or modify web projects. It is a simple addition to a configuration file that provides a significant upgrade in how machines perceive and interact with the work we build. Information about the package and the specification is available on GitHub and through the official documentation.

Official documentation: webdna.omraj.guru

I built a Claude Skill to automate brand-consistent social graphics (HTML to PNG) The Backstory

Om Rajguru — Sat, 04 Apr 2026 17:45:15 +0000

Automating Brand-Consistent Social Graphics with a Claude Skill

I’ve been using a custom Gemini setup to produce Instagram content for IBBE, a company I work with. While the workflow worked, it was fragile. I found myself repeating brand constraints, hex codes, and styling rules in every new session.

I wanted a way to formalize this process, something reusable, brand-aware, and easily installable. So, I built a Claude Skill that handles the heavy lifting of design consistency through a structured memory system.

How it Works

The skill transforms Claude from a general assistant into a specialized brand designer through three main phases:

The Onboarding Interview: The first time you request a design, Claude conducts a brand interview. It collects your color palette, typography preferences, design personality, and specific brand restrictions.
Persistent Memory: Once the profile is generated, you save it to memory. Every future session picks up exactly where you left off, ensuring your brand identity isn't "hallucinated" or lost between chats.
HTML-to-Image Pipeline: Claude generates a self-contained HTML file. This isn't just a mock-up; it includes a staging environment and an export button that uses html2canvas to download a high-resolution PNG directly from your browser.

The Aesthetic

The design language is opinionated and "dev-friendly." Every asset generated follows a consistent visual logic:

Structure: Inset cards with thick borders and hard offset shadows (Neo-brutalism style).
Textures: Dot grid backgrounds and rotated pill tags.
Dynamics: Carousel slides automatically alternate rotation directions, and visual metaphors are selected based on the slide's specific content.

What it Generates

Instagram Posts & Carousel Slides
OG Images for blog posts
Featured Images
General Visual Assets

Why HTML?

Generating graphics as HTML instead of raw images via DALL-E or Midjourney gives us pixel-perfect control over text. No more AI "gibberish" in your graphics. Since it's code, you can tweak the hex codes or layout in seconds before exporting.

Check out the repo here:

👉 https://github.com/omrajguru05/brand-social-design

I'd love to hear how you guys are using LLMs to automate your design workflows. Any suggestions for the memory system? Let's discuss in the comments!

Is Your Project Ready to Launch? I Built a Skill to Find Out

Om Rajguru — Wed, 01 Apr 2026 11:50:30 +0000

Shipping fast is great. Shipping ready is better. Here's how I stopped guessing and started knowing.

I used to think I had a solid launch checklist. It lived in a doc somewhere; it had checkboxes, and I told myself I would actually use it. Spoiler: I did not always use it. Features would go missing, a monitoring alert, or a README that said "TODO," or a rollback plan that existed only in my head. Every time, the feeling was the same. That quiet dread of realizing something got missed after it was already live.

So I built something to fix that. "Launch Readiness" is a skill I created to make pre-launch checks feel less like homework and more like a conversation. Instead of digging through a doc I inevitably forgot to update, I can just ask. It walks through the things that actually matter before a release: documentation, monitoring, rollback strategy, stakeholder sign-off, and more. It does not let me skip ahead. It asks, it listens, and it flags what is missing.

What I love most about it is that it changed how my team thinks about launches. We stopped treating readiness as a formality and started treating it as a real conversation. The skill is not a gatekeeper. It is more like a thoughtful colleague who asks the right questions at the right time and genuinely wants the launch to go well.

The best part is that you can try it yourself right now. Setup is straightforward, and within a few minutes you will have a launch process that actually holds up under pressure.

Launching something you built is exciting. I want that excitement to last past day one. This is my small contribution to making that happen.

omrajguru05 / launch-readiness

A Claude skill that audits your app before launch and gives you a readiness score, ranked issues, exact fixes, and copy-paste prompts. Install in one command. Updates at omrajguru.com

App Launch Readiness Skill for Claude

A Claude skill that audits your web app or SaaS product before launch. Give it your repo, your live URL, or both, and it returns a scored readiness report with every problem ranked by severity, exact fix instructions for each one, and copy-paste Claude prompts so you can resolve issues immediately without writing a single prompt yourself.

I built this because pre-launch checklists are either too generic to act on or scattered across a dozen blog posts. This skill pulls everything into one structured audit that runs inside Claude, reads your actual code or live URL, and tells you precisely what is broken and how to fix it.

I update this skill as new patterns, security issues, and launch gotchas emerge. All updates are published at omrajguru.com.

Installation

There are three ways to install depending on how you use Claude.

Option A: One-line

…

View on GitHub

I built a Formspree alternative because flat pricing is stupid

Om Rajguru — Sun, 22 Mar 2026 01:20:08 +0000

Aldform public beta: aldform.com

Formspree: $16/month flat. 10 or 10k submissions — same price.

Aldform: $1.20 per 1k submissions (₹100). 100 free/month.

Your HTML/CSS. We handle storage, email, API.

Alpha fixes shipped:

Server-side auth only, API keys
File uploads to S3 (10MB, images/PDF)
Polar billing, SES emails, dashboard

aldform.com/release-notes

Try it & And please let me know!!