The experience
Your money, on your schedule.
Adelanto is an account for people whose pay arrives on a schedule and whose bills do not. It lets an hourly worker take part of the pay they have already earned, days before payday, with no fee — and settles it automatically from the next deposit.
The demo is built from a released iOS product that Itexus took to production. The rules on screen are the product's own, carried over from its source: how much can be taken, where the slider starts, what the screen does when the available amount is gone. Those are not details anyone invents for a pitch.
It is not a bank and not a financial service, and nobody can sign up for it. Every name, amount and date is fictional, there is no server behind the demo, and nothing typed into it leaves the browser tab.
See the whole early-pay chain in one sitting
Understand what actually holds a payroll account
Scope a build with the real constraints visible
Who this is for
Five systems behind one screen.
Early pay looks like one screen and is really five systems. The demo is aimed at the people who have to assemble them.
Fintechs launching early pay
You have a launch date. The product needs payroll data, identity verification, card issuing, risk logic and regulatory disclosures — and most teams have never built any single one of those links, let alone the chain.
Partner banks and BaaS teams
You hold the payroll account and want to keep it. Early pay is the retention mechanic. The open question is which part of the chain you own and which part sits with the product on top.
Payroll-adjacent platforms
You already have the employer relationships and the pay data. This shows what a consumer financial product built on top of them looks like from the worker's side of the screen.
This positioning is a hypothesis drawn from the source product itself — its integrations, its deposit requirements, its localisation — not a client-confirmed segment.
The moment that sells it
$42.18 becomes $222.18 while you watch.
The account holds forty-two dollars. Payday is eleven days out, and the money is already earned — it just has not been paid yet. One slider, one button. Then three proofs land on a single screen at once.
The balance recalculates in front of you
A counter runs from the old number to the new one. Nothing reloads and nothing navigates away, so the buyer watches the change instead of being told about it.
The advance lands in the ordinary activity list
The same journal as the grocery run and the rent, with the running balance carried through. No separate wallet, no pending screen, no special case.
The time saved becomes a number
A timeline between today and payday shows the gap as eleven days rather than as a phrase. It is labelled on screen as proposed by Itexus — the source product states the benefit in words only.
Underneath it, the repayment plan: the amount, the date, and what happens on payday — automatically, from the next deposit, with no fee. That is the whole retention argument in one screen.
Suggested walkthrough
A guided path through the strongest moments.
Four minutes for the main flow. Around ten if you also walk the employer connection and the card controls.
Sign in
The phone number is already filled in. Press Send me a code, then Use code in the message that appears inside the demo.
The code fills in digit by digit and the account opens. No registration, no email gate, no credentials to look up.Read the account
A balance of $42.18, $180.00 available early, and an activity list where every row shows the balance after the operation.
You start exactly where the user starts: mid-pay-cycle, employer connected, available amount open, no advances taken yet.Open Early Pay
The service explains itself before any amount is chosen: no fee, settled from the next paycheck, and the date that settlement happens.
The terms are on the screen first. That ordering is the product's, not a demo convenience.Choose the amount
Move the slider. It already sits at the maximum, and the confirm button goes inactive at zero with an explanation rather than in silence.
This is the only decision in the flow, and it runs on the source product's own rules.Take the money
Press Get money now and stay on the screen.
The balance recalculates, the advance joins the activity list, the repayment plan appears, and the timeline shows eleven days earlier.Beyond the happy path
Scenarios: the situations the walkthrough does not reach.
The demo carries a Scenarios control in its top bar. It is a demo instrument rather than part of the product: each entry loads a different starting state — an edge case, a failure, a rule firing — and the screens recompute from it. The guided path shows the product working. The scenarios show what it does when the situation is not the ideal one.
One button, at any point in the demo.
Pick a scenario and the demo re-seeds itself and opens on the screen where that situation shows. Nothing has to be set up beforehand, and you can go back to the guided path whenever you want.
The states a product actually lives in
A limit that is used up, a figure that has gone stale, an approval that comes back as a question. These are the cases that decide whether a product survives contact with real users — and here each one is a state you can open, not a sentence you have to take on trust.
A rule you can trigger, then watch
A scenario sets up one condition and lets the system react to it. What appears on screen is computed by the same logic that runs the happy path, so the numbers, the blocks and the explanations behave as they do in the rest of the demo.
Your “what happens when…”, on the spot
The questions that decide a project are usually failure questions. If yours has a scenario, play it during the walkthrough and judge the answer on screen instead of waiting for a follow-up e-mail.
Scenarios are a demo control and never appear inside the product itself. Every state they load is built from the same fictional data, and Reset returns the demo to its clean starting seed.
Why this is not a mockup
Three details you only get from a shipped product.
Anyone can build a slider. These three behaviours are the kind that only appear after someone has watched real people use the product — and each one is carried over from the source implementation rather than designed for a demo.
The slider starts at the maximum
Not at zero. The product offers the full available amount by default, because that is what the person opening this screen came for. Someone made that decision, and the demo keeps it.
When the amount is used up, the slider disappears
It is replaced by an explanation of when the amount comes back. It does not sit there greyed out. Nobody designs that until they have watched users hit the wall and ask why.
Every transaction carries a running balance
Including the advance. In the source, the transaction model carries the balance after each operation, so the history answers “what did I have left” without any arithmetic.
Capability map
Clear about what you're experiencing.
Works in this demo
Implemented and ready to explore, end to end.
- Sign-in with a one-time code, including manual entry and resend
- The advance flow with all of the source product's rules
- Money landing instantly, the balance recalculating, the advance in history
- Repayment plan and advance history
- Card controls: spending limits, freeze and unfreeze
- Employer connection, from explanation to an open amount
- Three display versions with progress preserved when switching
- Guided Mode with per-screen hints tied to the scenario steps
- One-click session reset to a clean starting state
Simulated here
Behaves like the product, connected to nothing.
- SMS delivery — the message appears inside the demo, nothing is sent
- Disbursement — a deterministic local recalculation, not a ledger entry
- Settlement from payroll — shown as a plan; nothing is collected
- Employer connection — demo screens, not a payroll aggregator
- Card controls — state changes in the session, no issuer involved
- Service eligibility — a server-side flag in the source, seeded here
Ready to integrate
Candidate production sources. Not connected, not selected.
- Payroll aggregator for employer, schedule, and deposit data
- Partner bank or BaaS platform as system of record and card issuer
- KYC provider with document verification and liveness
- Bank account aggregator for funding from an outside account
- Device fraud detection and risk scoring
- In-app support and knowledge base
Completed and proposed
What came from the source, and what did not.
Two parts of the demo were completed rather than carried over, and one is a proposal. The difference is marked here and on screen, because it is what tells you which work Itexus actually did.
Sign-in and verification screens
Completed for the demoThe source product has the authorization layer and token storage, but no sign-in screen flow lives in the repository. Those screens were built for the demo.
Employer connection flow
Completed for the demoThe source has the payroll use-cases and the distribution configuration, but the connection screens belong to the aggregator's own SDK and are not part of the repository.
The days-earlier timeline
Proposed by ItexusThe source product states the benefit in words only. Showing it as a measurable gap between today and payday is our suggestion, and it carries that label on screen.
None of it changes regulated behaviour. The available amount, the scoring and the decision stay server-side, exactly as they are in the source.
However you open it
Three display versions of the same demo.
One runtime, one route, three layouts. Progress and entered values survive a switch, so a buyer can start on a laptop and finish on the phone in their hand without losing the flow.
App emulation
The default view. iOS idiom throughout: status bar, bottom tab bar, sheet transitions, a slider in native proportion. Framed as a phone on a large screen, unframed on a narrow one, and labelled Emulated app — not a native binary.
Adaptive web
A real two-column desktop layout rather than a stretched phone. Account and history on the left, the early-pay panel on the right, the repayment plan opening in place without a page change.
Narrow web
One column, four-item bottom navigation, a full-width slider, and the repayment plan as an expanding section. Touch targets sized for a thumb.
Narration built in
Guided Mode
A Guide toggle in the demo shell explains, on every screen, what is happening, what you can do, and where to go next — naming the product's rules outright. The hints are generated from the scenario steps, so they cannot contradict what is on screen. It is on for a first visit; turn it off when you are narrating yourself.
From demo to production
What each simulated part is standing in for.
The demo is honest about being a demo. Here is what each simulated area is standing in for, and what it becomes when the same product is built for real.
Every external category — payroll, identity, issuing, ledger, support, analytics — sits behind its own adapter with an explicit contract. That is not architectural taste: in the source product the payroll aggregator moved by environment configuration, and the last commits before release changed exactly that address. The provider is a variable.
Built to adapt
One product. A delivery chain you can reuse.
The source is a US consumer product for hourly workers. What carries into another market, segment or partner structure is the chain underneath it — and the discipline about which link belongs to whom.
Built from a released product
Not a mockup and not a prototype. The rules for choosing an advance amount come from the source implementation of an iOS product that Itexus took all the way to release.
One flow, one question answered
Access to your own money a few days early holds a payroll account harder than cashback does. The demo puts the whole retention argument on a single screen.
Three display versions
The buyer looks from whatever device is in their hand and sees the product, not an excuse. The main flow completes in every one of the three.
The whole chain, not a screen
Payroll data, the available amount, instant disbursement, automatic settlement. Itexus has built and shipped every link; scope and timeline are the conversation to have next.
Discuss with Itexus
Decisions to shape for your product
- Who is your system of record — a partner bank, a BaaS platform, or your own ledger?
- Where does payroll data come from, and how often are you willing to refresh it?
- Who decides the available amount, and on what data?
- What is the policy when a paycheck arrives late or short?
- Do you need a Spanish-language version from day one?
- How much of the support workload do you want to keep inside the app?
Demo access
Everything you need to start.
Nothing is required to start — the sign-in screen is pre-filled and the code arrives inside the demo. These values are listed so you know what you are looking at, and so you can retype them if you reset the session.
Account holder
Fictional. The number comes from the 555 range reserved for examples, and the code is deterministic — identical on every run. Press Use code in the message and it fills itself in.
(555) 0134418062Employer account
Fictional. Used only on the employer connection screen, and never sent anywhere. The screen does not depict a successful sign-in to any real service.
m.alvarezdemo-valueBefore you begin
Demo boundaries and data policy.
Known limitations
- The demo plays one state: mid-pay-cycle, employer connected, amount available, no advances taken. An overdue advance, a switched-off service, or a declined request are not played out.
- Identity verification is not reproduced. Simulating a regulated step in a financial product is off limits, so onboarding appears only as a short sign-in without identity checks.
- Native capabilities of the source do not carry over to a browser: camera card scanning, Apple Wallet provisioning, and the device-fraud SDK.
- Transfers, the ATM map, the referral programme and support chat exist in the source product but are not played out here. They are listed as scope, never shown as buttons that do nothing.
- The demo clock is fixed. “Eleven days to payday” comes from the seed rather than from your system time, so the scenario reads the same next month.
- Every product statement describes the source as of its last release in October 2021. What happened to it after that, the demo does not claim.
Data and safety
- All data in this demo is fictional and deterministically generated.
- Nothing you do here happens in any production system.
- Do not enter real personal, payment or identity data.
- Simulated identity, payment, payroll and support providers are not connected to production.
- There is no server behind the demo — what you type stays in your browser tab.
- Completed and proposed functionality is marked on screen and is not an existing feature of the source product.
Provenance
- Source product
- A released iOS application; last release October 2021. Every product statement is tied to that point in time.
- Positioning
- A market hypothesis derived from the source product, not a measured or client-confirmed segment.
- Conformance
- No compliance audit has been performed, and the demo makes no conformance statement about any regulation.
- Content version
- 1.0.0, verified against the deployed demo on 30 July 2026.