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.