This cover page states three things a reader needs before turning the page: what Shiftly is, what stage it is at, and what the ask is. Shiftly is positioned as "the labor-cost operating system for hourly teams," chosen over "scheduling software" because the value sits in cost control, not the calendar. The category already exists; legacy scheduling tools have shipped calendar features for a decade. The tagline has to signal the difference on first read: forecasting demand and holding labor cost to a target, not publishing a roster. Below the tagline sit four constants that recur on every page of the deck and this memo: the round (Seed), the ask ($1.5M), the date (July 2026), and the confidential marker. They are pulled forward here so a reader can answer stage, amount, and timing in under five seconds, before reading a single argument. Two figures on this page are worth flagging as claims that go beyond the client's own description and should carry a source note before this memo circulates further. First, the 80M-plus US hourly workers scheduled without purpose-built software, which feeds the market sizing on the Market slide and is currently taken as a market-research input rather than a client assertion. Second, the pre-money figure that recurs on the Ask slide, $21.4M pre-money on a $1.0M tranche at 4.45% dilution, which is a modeled output of the five-method valuation blend described later, not a number the client set unilaterally. Everything else on this page, the company name, the tagline, the round type, the headline ask, and the date, comes directly from the client and matches the deck it mirrors word for word. The design intent of the cover is restraint: one tagline, four facts, no argument yet. The argument, starting with the cost of the status quo, begins on the next page. Read together with the rest of this memo, the cover is best understood as a promise the following fourteen slides have to keep: that the tagline is not aspirational language but a literal description of what the product does, that the round and ask figures are exact matches to the Ask slide rather than rounded approximations, and that every subsequent number in the memo traces back to either a stated client fact or a labeled model output, never an unlabeled estimate introduced for the first time mid-document.

This cover page states three things a reader needs before turning the page: what Shiftly is, what stage it is at, and what the ask is. Shiftly is positioned as "the labor-cost operating system for hourly teams," chosen over "scheduling software" because the value sits in cost control, not the calendar. The category already exists; legacy scheduling tools have shipped calendar features for a decade. The tagline has to signal the difference on first read: forecasting demand and holding labor cost to a target, not publishing a roster.

Below the tagline sit four constants that recur on every page of the deck and this memo: the round (Seed), the ask ($1.5M), the date (July 2026), and the confidential marker. They are pulled forward here so a reader can answer stage, amount, and timing in under five seconds, before reading a single argument.

Two figures on this page are worth flagging as claims that go beyond the client's own description and should carry a source note before this memo circulates further. First, the 80M-plus US hourly workers scheduled without purpose-built software, which feeds the market sizing on the Market slide and is currently taken as a market-research input rather than a client assertion. Second, the pre-money figure that recurs on the Ask slide, $21.4M pre-money on a $1.0M tranche at 4.45% dilution, which is a modeled output of the five-method valuation blend described later, not a number the client set unilaterally.

Everything else on this page, the company name, the tagline, the round type, the headline ask, and the date, comes directly from the client and matches the deck it mirrors word for word. The design intent of the cover is restraint: one tagline, four facts, no argument yet. The argument, starting with the cost of the status quo, begins on the next page.

Read together with the rest of this memo, the cover is best understood as a promise the following fourteen slides have to keep: that the tagline is not aspirational language but a literal description of what the product does, that the round and ask figures are exact matches to the Ask slide rather than rounded approximations, and that every subsequent number in the memo traces back to either a stated client fact or a labeled model output, never an unlabeled estimate introduced for the first time mid-document.

This slide names the specific failure Shiftly is built against: hourly-team managers still build schedules in spreadsheets, with no visibility into labor cost until payroll actually runs. By the time a manager sees the number, the week is already worked and the cost is already locked in. The tool used to build the schedule, the spreadsheet, has no connection to the forecast of how busy the location will actually be, so the schedule is a guess dressed up as a plan. Two consequences follow directly from that gap, and both are stated on the slide rather than implied. Chronic understaffing and overstaffing: managers over-schedule to avoid the risk of being short-handed during a rush, or under-schedule to protect a cost target they cannot see in real time, and both errors are expensive in opposite directions. And high frontline turnover tied to unpredictable scheduling: hourly workers who cannot count on a stable, visible schedule leave for employers who can offer one, and replacing them costs more than the scheduling software ever would. The reason this problem persists industry-wide rather than getting solved by any one chain internally is structural, not a failure of any one manager. Spreadsheets are free and familiar, and nothing forces a reconciliation of a draft schedule against a labor-cost target before it goes live. The forecasting data required to do that has historically lived in a different system than the scheduling tool, so no single interface could show cost-versus-forecast before the fact. Every claim on this slide describes an operating reality inside hourly-team businesses that the founding team has lived directly, drawn from the CEO's background running schedules across a 120-location restaurant group, and is not an independently sourced statistic. The market-scale version of this same problem, how many workers and dollars it touches nationally, is quantified separately on the Market slide rather than here, where the point is the mechanism of the failure, not its size. This slide does not assert that every hourly-team business is mismanaged, only that the tooling available today, a spreadsheet with no live connection to a demand forecast or cost target, structurally prevents even a skilled manager from seeing the cost of a decision before it is made. That distinction, a tooling gap rather than a competence gap, is why software is the right fix, not more training.

This slide names the specific failure Shiftly is built against: hourly-team managers still build schedules in spreadsheets, with no visibility into labor cost until payroll actually runs. By the time a manager sees the number, the week is already worked and the cost is already locked in. The tool used to build the schedule, the spreadsheet, has no connection to the forecast of how busy the location will actually be, so the schedule is a guess dressed up as a plan.

Two consequences follow directly from that gap, and both are stated on the slide rather than implied. Chronic understaffing and overstaffing: managers over-schedule to avoid the risk of being short-handed during a rush, or under-schedule to protect a cost target they cannot see in real time, and both errors are expensive in opposite directions. And high frontline turnover tied to unpredictable scheduling: hourly workers who cannot count on a stable, visible schedule leave for employers who can offer one, and replacing them costs more than the scheduling software ever would.

The reason this problem persists industry-wide rather than getting solved by any one chain internally is structural, not a failure of any one manager. Spreadsheets are free and familiar, and nothing forces a reconciliation of a draft schedule against a labor-cost target before it goes live. The forecasting data required to do that has historically lived in a different system than the scheduling tool, so no single interface could show cost-versus-forecast before the fact.

Every claim on this slide describes an operating reality inside hourly-team businesses that the founding team has lived directly, drawn from the CEO's background running schedules across a 120-location restaurant group, and is not an independently sourced statistic. The market-scale version of this same problem, how many workers and dollars it touches nationally, is quantified separately on the Market slide rather than here, where the point is the mechanism of the failure, not its size.

This slide does not assert that every hourly-team business is mismanaged, only that the tooling available today, a spreadsheet with no live connection to a demand forecast or cost target, structurally prevents even a skilled manager from seeing the cost of a decision before it is made. That distinction, a tooling gap rather than a competence gap, is why software is the right fix, not more training.

This slide answers the problem page directly: Shiftly closes the gap between forecast and schedule by putting both in the same system. It reads hourly demand signals from a location's point-of-sale and foot-traffic data, uses that forecast to auto-build a draft schedule that is built to hit a labor-cost target rather than just fill shifts, and then shows the manager live labor cost against forecasted sales while the schedule is still editable, not after payroll has already run. The sequencing matters. Forecast comes first, draft schedule comes second, and the cost-versus-sales view stays live throughout, so a manager approving a schedule can see the financial consequence of every change before it is committed rather than reading it off a payroll report days later. That live view is the mechanism that fixes the chronic over- and understaffing named on the Problem slide, because the manager is no longer guessing at a cost, they are watching one. The second half of the solution addresses the turnover side of the problem: employees get shift-swap, availability, and pay-to-date visibility directly, which gives frontline staff the stability and transparency the Problem slide identifies as missing. This is not a bolt-on feature, it is built on the same forecast-and-schedule data the manager console uses, so a swap request is evaluated against the same labor-cost target the schedule was built to hit. Every element described here, forecast-from-POS, auto-build to a cost target, live cost-versus-sales, and worker-side swap and pay visibility, is a direct capability of the product as described by the client and is carried forward unchanged into the Product and How It Works slides that follow. No claim on this page is a projection; it describes what the system does, not what it is expected to do once built. The competitive framing of why this combination does not already exist among incumbents is reserved for the Competitive Advantage slide rather than argued here. One implication worth drawing out here: the solution is a single connected loop, not three separate features bundled for convenience. Removing the forecast leaves an auto-scheduler with nothing accurate to build against; removing the live cost view leaves a manager approving a draft blind; removing the worker-facing layer leaves the turnover half of the Problem slide unaddressed. The loop, not any one piece, is what this memo refers back to on value and pricing.

This slide answers the problem page directly: Shiftly closes the gap between forecast and schedule by putting both in the same system. It reads hourly demand signals from a location's point-of-sale and foot-traffic data, uses that forecast to auto-build a draft schedule that is built to hit a labor-cost target rather than just fill shifts, and then shows the manager live labor cost against forecasted sales while the schedule is still editable, not after payroll has already run.

The sequencing matters. Forecast comes first, draft schedule comes second, and the cost-versus-sales view stays live throughout, so a manager approving a schedule can see the financial consequence of every change before it is committed rather than reading it off a payroll report days later. That live view is the mechanism that fixes the chronic over- and understaffing named on the Problem slide, because the manager is no longer guessing at a cost, they are watching one.

The second half of the solution addresses the turnover side of the problem: employees get shift-swap, availability, and pay-to-date visibility directly, which gives frontline staff the stability and transparency the Problem slide identifies as missing. This is not a bolt-on feature, it is built on the same forecast-and-schedule data the manager console uses, so a swap request is evaluated against the same labor-cost target the schedule was built to hit.

Every element described here, forecast-from-POS, auto-build to a cost target, live cost-versus-sales, and worker-side swap and pay visibility, is a direct capability of the product as described by the client and is carried forward unchanged into the Product and How It Works slides that follow. No claim on this page is a projection; it describes what the system does, not what it is expected to do once built. The competitive framing of why this combination does not already exist among incumbents is reserved for the Competitive Advantage slide rather than argued here.

One implication worth drawing out here: the solution is a single connected loop, not three separate features bundled for convenience. Removing the forecast leaves an auto-scheduler with nothing accurate to build against; removing the live cost view leaves a manager approving a draft blind; removing the worker-facing layer leaves the turnover half of the Problem slide unaddressed. The loop, not any one piece, is what this memo refers back to on value and pricing.

This slide breaks the solution into the three pieces an investor would actually need to see working: a manager console, a worker app, and the integration layer connecting both to the systems a location already runs. The manager console carries auto-scheduling, the live labor-cost view, and shift approvals, which is where the labor-cost target set on the Solution slide actually gets enforced day to day. The worker app carries calendar, swaps, availability, and pay-to-date, which is the transparency layer aimed directly at the turnover problem named earlier in the memo. The third piece, POS and payroll integrations, is what makes the first two pieces possible rather than a nice-to-have. Without a live read of point-of-sale and foot-traffic data, the forecasting engine has nothing to forecast from, and without a payroll connection, the pay-to-date figure a worker sees in the app is a guess rather than a fact. This is why the product is described as three parts rather than two: the integration layer is load-bearing for both the manager and worker experience, not a back-office detail. This structure also explains the pricing model described on the Business Model slide, $6 per scheduled employee per month billed per location, because both the manager console and the worker app are licensed together per employee scheduled, rather than sold as separate modules. A location does not buy "scheduling" and "the worker app" separately; it buys Shiftly for every hourly employee on the schedule. The product description here is stated at the level the client provided it: three components, a defined role for each, and the dependency between them. No feature count, release date, or technical architecture claim beyond what is listed above should be read into this slide; the mechanism by which the manager console actually forecasts and auto-builds is covered next, on the How It Works slide. For an investor evaluating build complexity, the honest read of this slide is that the integration layer, not the two front-end applications, is where most of the technical risk sits, since a manager console and a worker app are well-understood interface patterns, while a forecasting engine wired reliably into a location's live POS and payroll feeds is the harder engineering problem and the one the CTO's prior experience, detailed on the Team slide, is most directly relevant to.

This slide breaks the solution into the three pieces an investor would actually need to see working: a manager console, a worker app, and the integration layer connecting both to the systems a location already runs. The manager console carries auto-scheduling, the live labor-cost view, and shift approvals, which is where the labor-cost target set on the Solution slide actually gets enforced day to day. The worker app carries calendar, swaps, availability, and pay-to-date, which is the transparency layer aimed directly at the turnover problem named earlier in the memo.

The third piece, POS and payroll integrations, is what makes the first two pieces possible rather than a nice-to-have. Without a live read of point-of-sale and foot-traffic data, the forecasting engine has nothing to forecast from, and without a payroll connection, the pay-to-date figure a worker sees in the app is a guess rather than a fact. This is why the product is described as three parts rather than two: the integration layer is load-bearing for both the manager and worker experience, not a back-office detail.

This structure also explains the pricing model described on the Business Model slide, $6 per scheduled employee per month billed per location, because both the manager console and the worker app are licensed together per employee scheduled, rather than sold as separate modules. A location does not buy "scheduling" and "the worker app" separately; it buys Shiftly for every hourly employee on the schedule.

The product description here is stated at the level the client provided it: three components, a defined role for each, and the dependency between them. No feature count, release date, or technical architecture claim beyond what is listed above should be read into this slide; the mechanism by which the manager console actually forecasts and auto-builds is covered next, on the How It Works slide.

For an investor evaluating build complexity, the honest read of this slide is that the integration layer, not the two front-end applications, is where most of the technical risk sits, since a manager console and a worker app are well-understood interface patterns, while a forecasting engine wired reliably into a location's live POS and payroll feeds is the harder engineering problem and the one the CTO's prior experience, detailed on the Team slide, is most directly relevant to.

This slide walks the mechanism behind the Product slide in sequence, because the order of operations is the actual innovation, not any single step in isolation. Step one, Shiftly pulls hourly demand signals from a location's point-of-sale and foot-traffic data. Step two, it turns that signal into an hourly demand forecast rather than a flat weekly estimate, since labor need inside a shift, not just across a week, is what drives cost. Step three, it auto-builds a draft schedule against that forecast, built to hit a labor-cost target set for the location rather than simply covering every open slot. Step four, the manager sees live labor cost plotted against forecasted sales while the draft is still editable, so any manual change shows its cost impact immediately. Step five, once approved, the same schedule and cost data feed the worker app, so shift-swap requests, availability changes, and pay-to-date figures are all checked against the schedule that was actually built to hit the target, not a stale copy of it. The bridge from this slide to the rest of the memo is direct: this sequence is what makes the $6-per-scheduled-employee pricing on the Business Model slide defensible, since the cost the software controls is worth many multiples of the fee once understaffing, overstaffing, and turnover are reduced. It is also what makes the forecast-first, live-labor-cost-to-sales positioning on the Competitive Advantage slide credible rather than a marketing claim, because the mechanism described here is a closed loop between forecast, schedule, and worker, not a scheduling calendar with a cost estimate bolted on afterward. Each step described is a capability of the product as the client describes it today. No claim here should be read as a roadmap item; where a capability is planned rather than live, it is addressed separately on the Roadmap slide. The reason this memo walks the mechanism step by step rather than describing it as a single black-box forecast is that each step is independently checkable in a live demo: a diligence reviewer can watch a forecast get generated, watch the draft schedule build against it, edit the draft and watch the cost figure move, and then see the same shift reflected instantly in the worker app. That checkability is itself part of the credibility case for the product, separate from any number on the Forecast slide.

This slide walks the mechanism behind the Product slide in sequence, because the order of operations is the actual innovation, not any single step in isolation. Step one, Shiftly pulls hourly demand signals from a location's point-of-sale and foot-traffic data. Step two, it turns that signal into an hourly demand forecast rather than a flat weekly estimate, since labor need inside a shift, not just across a week, is what drives cost. Step three, it auto-builds a draft schedule against that forecast, built to hit a labor-cost target set for the location rather than simply covering every open slot. Step four, the manager sees live labor cost plotted against forecasted sales while the draft is still editable, so any manual change shows its cost impact immediately. Step five, once approved, the same schedule and cost data feed the worker app, so shift-swap requests, availability changes, and pay-to-date figures are all checked against the schedule that was actually built to hit the target, not a stale copy of it.

The bridge from this slide to the rest of the memo is direct: this sequence is what makes the $6-per-scheduled-employee pricing on the Business Model slide defensible, since the cost the software controls is worth many multiples of the fee once understaffing, overstaffing, and turnover are reduced. It is also what makes the forecast-first, live-labor-cost-to-sales positioning on the Competitive Advantage slide credible rather than a marketing claim, because the mechanism described here is a closed loop between forecast, schedule, and worker, not a scheduling calendar with a cost estimate bolted on afterward.

Each step described is a capability of the product as the client describes it today. No claim here should be read as a roadmap item; where a capability is planned rather than live, it is addressed separately on the Roadmap slide.

The reason this memo walks the mechanism step by step rather than describing it as a single black-box forecast is that each step is independently checkable in a live demo: a diligence reviewer can watch a forecast get generated, watch the draft schedule build against it, edit the draft and watch the cost figure move, and then see the same shift reflected instantly in the worker app. That checkability is itself part of the credibility case for the product, separate from any number on the Forecast slide.

This slide states the return a customer gets for adopting Shiftly, and it is deliberately framed around the same two failure modes named on the Problem slide: labor cost that is invisible until payroll runs, and turnover driven by unpredictable scheduling. The value case is not "better software," it is "a labor line that stops surprising you and a frontline that stops leaving." On the cost side, the live labor-cost-versus-forecasted-sales view described on the Solution and How It Works slides means a manager can correct an over- or under-staffed draft before it is worked, rather than discovering the miss after payroll. That is the direct mechanism by which Shiftly claims to reduce chronic understaffing and overstaffing, and it is the same mechanism the pricing model is built around: a location pays $6 per scheduled employee per month, a cost that is straightforward to justify against labor-cost variance the tool is built to catch before it happens. On the retention side, the worker app's calendar, swap, availability, and pay-to-date visibility gives hourly staff the predictability the Problem slide identifies as missing from spreadsheet-built schedules. Reduced frontline turnover is a real cost saving for a multi-location operator, since replacing hourly staff is expensive relative to the fee, but the scale of that saving is not separately modeled in this memo and should be treated as directional rather than quantified. For the buyer specifically, a regional multi-location chain of 10 to 100 locations as named on the Go To Market slide, the value proposition compounds with scale: every additional location added to the account adds the same per-employee fee and the same cost-and-turnover benefit, which is the mechanical basis for the land-and-expand motion described later in this memo. Nothing on this slide introduces a number not already anchored elsewhere in the deck; it restates the Problem and Solution slides in terms of what the customer receives rather than what the product does. A useful summary test for this slide: if a chain adopts Shiftly and, six months later, cannot point to a measurably tighter gap between forecasted and actual labor cost, and cannot point to lower turnover among scheduled staff, the value proposition as stated here has not been delivered. That is the standard this memo holds the product to, and it is the same standard a reference customer conversation should be tested against during diligence.

This slide states the return a customer gets for adopting Shiftly, and it is deliberately framed around the same two failure modes named on the Problem slide: labor cost that is invisible until payroll runs, and turnover driven by unpredictable scheduling. The value case is not "better software," it is "a labor line that stops surprising you and a frontline that stops leaving."

On the cost side, the live labor-cost-versus-forecasted-sales view described on the Solution and How It Works slides means a manager can correct an over- or under-staffed draft before it is worked, rather than discovering the miss after payroll. That is the direct mechanism by which Shiftly claims to reduce chronic understaffing and overstaffing, and it is the same mechanism the pricing model is built around: a location pays $6 per scheduled employee per month, a cost that is straightforward to justify against labor-cost variance the tool is built to catch before it happens.

On the retention side, the worker app's calendar, swap, availability, and pay-to-date visibility gives hourly staff the predictability the Problem slide identifies as missing from spreadsheet-built schedules. Reduced frontline turnover is a real cost saving for a multi-location operator, since replacing hourly staff is expensive relative to the fee, but the scale of that saving is not separately modeled in this memo and should be treated as directional rather than quantified.

For the buyer specifically, a regional multi-location chain of 10 to 100 locations as named on the Go To Market slide, the value proposition compounds with scale: every additional location added to the account adds the same per-employee fee and the same cost-and-turnover benefit, which is the mechanical basis for the land-and-expand motion described later in this memo. Nothing on this slide introduces a number not already anchored elsewhere in the deck; it restates the Problem and Solution slides in terms of what the customer receives rather than what the product does.

A useful summary test for this slide: if a chain adopts Shiftly and, six months later, cannot point to a measurably tighter gap between forecasted and actual labor cost, and cannot point to lower turnover among scheduled staff, the value proposition as stated here has not been delivered. That is the standard this memo holds the product to, and it is the same standard a reference customer conversation should be tested against during diligence.

This slide itemizes the five capabilities that make up the product described on the earlier Product and How It Works slides, presented as discrete, demoable features rather than as a single mechanism. First, demand forecasting from POS and foot-traffic data, which is the input every other feature depends on. Second, auto-scheduling that drafts a schedule built to hit a labor-cost target, rather than a template that simply fills open shifts. Third, live labor-cost-to-forecasted-sales tracking, visible to the manager while a draft is still editable. Fourth, manager approvals, the control point where a human confirms the auto-built draft before it goes live. Fifth, the worker-facing set, shift-swap, availability, and pay-to-date, which is the transparency layer aimed at the turnover problem. These five are listed in the same order they operate in practice, forecast, draft, cost view, approval, worker access, and none is separable from the others in terms of value: the forecasting feature is inert without the auto-scheduler to act on it, and the auto-scheduler is a black box without the live cost view that lets a manager trust and adjust it. That interdependency is why Shiftly is priced and sold as one product per scheduled employee, at $6 per employee per month billed per location, rather than as separable modules a customer could buy piecemeal. Each feature named here is a live capability of the product as described directly by the client, not a planned addition. Where the roadmap adds further capability on top of these five, for example expanded integrations or new fair-scheduling-law compliance tooling, that is addressed on the Roadmap slide rather than claimed here as already shipped. The purpose of this slide inside the memo is to give a reader a checklist against which to evaluate a live product demo, not to introduce new numbers. For diligence purposes, each of the five items above should be treated as a separate demo checkpoint: forecasting accuracy against a location's actual historical demand, the auto-scheduler's draft against a stated cost target, the live-view's responsiveness when a draft is edited, the approval flow's audit trail, and the worker app's swap and pay-to-date accuracy. A reviewer who confirms all five in sequence has effectively confirmed the mechanism on the How It Works slide end to end.

This slide itemizes the five capabilities that make up the product described on the earlier Product and How It Works slides, presented as discrete, demoable features rather than as a single mechanism. First, demand forecasting from POS and foot-traffic data, which is the input every other feature depends on. Second, auto-scheduling that drafts a schedule built to hit a labor-cost target, rather than a template that simply fills open shifts. Third, live labor-cost-to-forecasted-sales tracking, visible to the manager while a draft is still editable. Fourth, manager approvals, the control point where a human confirms the auto-built draft before it goes live. Fifth, the worker-facing set, shift-swap, availability, and pay-to-date, which is the transparency layer aimed at the turnover problem.

These five are listed in the same order they operate in practice, forecast, draft, cost view, approval, worker access, and none is separable from the others in terms of value: the forecasting feature is inert without the auto-scheduler to act on it, and the auto-scheduler is a black box without the live cost view that lets a manager trust and adjust it. That interdependency is why Shiftly is priced and sold as one product per scheduled employee, at $6 per employee per month billed per location, rather than as separable modules a customer could buy piecemeal.

Each feature named here is a live capability of the product as described directly by the client, not a planned addition. Where the roadmap adds further capability on top of these five, for example expanded integrations or new fair-scheduling-law compliance tooling, that is addressed on the Roadmap slide rather than claimed here as already shipped. The purpose of this slide inside the memo is to give a reader a checklist against which to evaluate a live product demo, not to introduce new numbers.

For diligence purposes, each of the five items above should be treated as a separate demo checkpoint: forecasting accuracy against a location's actual historical demand, the auto-scheduler's draft against a stated cost target, the live-view's responsiveness when a draft is edited, the approval flow's audit trail, and the worker app's swap and pay-to-date accuracy. A reviewer who confirms all five in sequence has effectively confirmed the mechanism on the How It Works slide end to end.

Two structural shifts explain why this is the moment for a forecast-first labor-cost tool rather than five years ago. The first is regulatory: fair-scheduling laws, which require advance notice of shifts and compensation for last-minute changes, have been expanding city by city across the US rather than arriving as a single federal rule. Each new city that adopts one raises the cost of the spreadsheet-and-guesswork status quo named on the Problem slide, since a schedule built without a forecast is also a schedule built without the lead time these laws now require, and every fine a chain pays for a late change is a direct, visible cost that a forecast-first tool is built to prevent. The second is technical: point-of-sale and payroll platforms have only recently opened the data APIs a forecasting engine actually needs. Demand forecasting of the kind Shiftly runs depends on a live read of transaction and foot-traffic data, and on a live connection to payroll so the pay-to-date figure in the worker app is accurate rather than estimated. Both data paths were closed or partner-gated on most major platforms until recently, which is why a product built on this combination was not straightforwardly buildable at scale before now. Together, these two shifts change the buyer's calculus rather than just the vendor's. A regional chain evaluating scheduling software today is weighing compliance exposure that grows with every new city on the fair-scheduling list, against a category of tool, calendar-first schedulers and payroll-suite bolt-ons, that was not designed to forecast against a labor-cost target in the first place. Spreadsheets, the real incumbent as described on the Competitive Advantage slide, cannot close either gap on their own. Neither the pace of city-by-city fair-scheduling adoption nor the exact timing of API access across every POS and payroll provider is independently verified in this memo; both are stated as directional market conditions supplied by the client and should be checked against public legislative trackers and partner-program documentation before this memo is finalized for external circulation. The practical takeaway for an investor is timing risk in both directions: move early enough and the fair-scheduling and open-API tailwinds are still building rather than fully priced in by every competitor; wait and a payroll-suite incumbent, named directly on the Competitive Advantage slide, has time to bolt forecasting onto its existing distribution before Shiftly establishes the land-and-expand base described on the Go To Market slide.

Two structural shifts explain why this is the moment for a forecast-first labor-cost tool rather than five years ago. The first is regulatory: fair-scheduling laws, which require advance notice of shifts and compensation for last-minute changes, have been expanding city by city across the US rather than arriving as a single federal rule. Each new city that adopts one raises the cost of the spreadsheet-and-guesswork status quo named on the Problem slide, since a schedule built without a forecast is also a schedule built without the lead time these laws now require, and every fine a chain pays for a late change is a direct, visible cost that a forecast-first tool is built to prevent.

The second is technical: point-of-sale and payroll platforms have only recently opened the data APIs a forecasting engine actually needs. Demand forecasting of the kind Shiftly runs depends on a live read of transaction and foot-traffic data, and on a live connection to payroll so the pay-to-date figure in the worker app is accurate rather than estimated. Both data paths were closed or partner-gated on most major platforms until recently, which is why a product built on this combination was not straightforwardly buildable at scale before now.

Together, these two shifts change the buyer's calculus rather than just the vendor's. A regional chain evaluating scheduling software today is weighing compliance exposure that grows with every new city on the fair-scheduling list, against a category of tool, calendar-first schedulers and payroll-suite bolt-ons, that was not designed to forecast against a labor-cost target in the first place. Spreadsheets, the real incumbent as described on the Competitive Advantage slide, cannot close either gap on their own.

Neither the pace of city-by-city fair-scheduling adoption nor the exact timing of API access across every POS and payroll provider is independently verified in this memo; both are stated as directional market conditions supplied by the client and should be checked against public legislative trackers and partner-program documentation before this memo is finalized for external circulation.

The practical takeaway for an investor is timing risk in both directions: move early enough and the fair-scheduling and open-API tailwinds are still building rather than fully priced in by every competitor; wait and a payroll-suite incumbent, named directly on the Competitive Advantage slide, has time to bolt forecasting onto its existing distribution before Shiftly establishes the land-and-expand base described on the Go To Market slide.

This slide sizes the opportunity in three steps, top-down to bottom-up: a total addressable market of $18B, a serviceable addressable market of $4.2B, and a serviceable obtainable market of $210M. The starting point for all three is a single client-supplied figure: more than 80 million US hourly workers are currently scheduled without purpose-built software, meaning on spreadsheets, paper, or generic calendar tools rather than a forecast-driven system. The TAM of $18B represents the labor-cost-and-scheduling software spend implied if every one of those 80 million-plus hourly workers were served by a product priced in Shiftly's range. The SAM of $4.2B narrows that to the segment Shiftly's go-to-market actually targets, regional multi-location retail, restaurant, and hospitality chains, as opposed to single-location independents or enterprise accounts served through a different motion. The SOM of $210M is the realistic capture target within a defined selling window given a direct-sales, land-and-expand strategy rather than a platform-distribution one, and it is the figure that should be checked most closely against the financial model's bookings assumptions, since it is the ceiling the Year 5 revenue projection of $6.5M is measured against. A second market dynamic sits alongside the size figures rather than inside them: fair-scheduling laws are expanding city by city, which does not change the size of the market so much as it changes the urgency of buying into it, a point developed fully on the Why Now slide. Readers should treat that regulatory trend as context for the market's growth rate, not as an input to the TAM, SAM, or SOM figures themselves, which are calculated independently. The 80-million-worker base figure and the $18B/$4.2B/$210M breakdown are presented here as supplied; none of the four figures is independently re-derived in this memo, and each should carry a labor-statistics or industry-report citation before the memo is shared outside the immediate deal team. Investors should also read the SOM figure against the Forecast slide's Year 5 revenue of $6.5M: at $210M, the model's Year 5 target represents roughly 3% penetration of the serviceable obtainable market, which is a reasonable five-year capture rate for a direct-sales motion targeting a well-defined 10-to-100-location buyer segment, rather than an aggressive assumption that requires near-total category capture to hold.

This slide sizes the opportunity in three steps, top-down to bottom-up: a total addressable market of $18B, a serviceable addressable market of $4.2B, and a serviceable obtainable market of $210M. The starting point for all three is a single client-supplied figure: more than 80 million US hourly workers are currently scheduled without purpose-built software, meaning on spreadsheets, paper, or generic calendar tools rather than a forecast-driven system.

The TAM of $18B represents the labor-cost-and-scheduling software spend implied if every one of those 80 million-plus hourly workers were served by a product priced in Shiftly's range. The SAM of $4.2B narrows that to the segment Shiftly's go-to-market actually targets, regional multi-location retail, restaurant, and hospitality chains, as opposed to single-location independents or enterprise accounts served through a different motion. The SOM of $210M is the realistic capture target within a defined selling window given a direct-sales, land-and-expand strategy rather than a platform-distribution one, and it is the figure that should be checked most closely against the financial model's bookings assumptions, since it is the ceiling the Year 5 revenue projection of $6.5M is measured against.

A second market dynamic sits alongside the size figures rather than inside them: fair-scheduling laws are expanding city by city, which does not change the size of the market so much as it changes the urgency of buying into it, a point developed fully on the Why Now slide. Readers should treat that regulatory trend as context for the market's growth rate, not as an input to the TAM, SAM, or SOM figures themselves, which are calculated independently.

The 80-million-worker base figure and the $18B/$4.2B/$210M breakdown are presented here as supplied; none of the four figures is independently re-derived in this memo, and each should carry a labor-statistics or industry-report citation before the memo is shared outside the immediate deal team.

Investors should also read the SOM figure against the Forecast slide's Year 5 revenue of $6.5M: at $210M, the model's Year 5 target represents roughly 3% penetration of the serviceable obtainable market, which is a reasonable five-year capture rate for a direct-sales motion targeting a well-defined 10-to-100-location buyer segment, rather than an aggressive assumption that requires near-total category capture to hold.

The pricing model is a single number: $6 per scheduled employee per month, billed per location. Every other figure in this memo's financial narrative, the Year 1 to Year 5 revenue path, the Year 5 EBITDA margin, and the location and user counts on the Forecast slide, is built up from this one unit price multiplied by scheduled employees and locations, so it is worth reading closely rather than as a footnote. Two design choices are worth naming explicitly. First, the fee is charged per scheduled employee, not per manager seat or flat per location, so the manager console and worker app described on the Product slide are sold as one bundle; a location does not pay extra to unlock the worker-facing swap and pay-to-date features. Second, billing is anchored to the location, which matches how a regional chain actually buys software, one contract that scales as locations are added, the mechanical basis for the land-and-expand motion on the Go To Market slide: an existing customer growing from, say, 20 to 40 locations doubles its Shiftly spend without a new sales cycle. This pricing model connects directly to the Year 5 target of 8,770 total locations and users named on the Forecast slide, and to the path from $597K in Year 1 revenue to $6.5M in Year 5, an 82% five-year compound growth rate. None of those figures requires a second pricing tier or an upsell assumption to work; the model as described is a single, simple per-employee rate applied at growing scale. The $6 figure and the per-location billing structure are both stated directly by the client as the operative pricing model today. Whether this rate holds as the product adds fair-scheduling-law compliance tooling or additional integrations, both flagged on the Roadmap slide, is not addressed in this memo and should be confirmed before this figure is used in any external pricing conversation. One further point worth stating: because the fee is per scheduled employee rather than per manager or per site, gross revenue moves with headcount volatility inside a location, not just with locations signed. A chain with heavy seasonal staffing should show some quarter-to-quarter variance under this model even with zero new locations added, a normal feature of the pricing structure and not a churn signal on its own.

The pricing model is a single number: $6 per scheduled employee per month, billed per location. Every other figure in this memo's financial narrative, the Year 1 to Year 5 revenue path, the Year 5 EBITDA margin, and the location and user counts on the Forecast slide, is built up from this one unit price multiplied by scheduled employees and locations, so it is worth reading closely rather than as a footnote.

Two design choices are worth naming explicitly. First, the fee is charged per scheduled employee, not per manager seat or flat per location, so the manager console and worker app described on the Product slide are sold as one bundle; a location does not pay extra to unlock the worker-facing swap and pay-to-date features. Second, billing is anchored to the location, which matches how a regional chain actually buys software, one contract that scales as locations are added, the mechanical basis for the land-and-expand motion on the Go To Market slide: an existing customer growing from, say, 20 to 40 locations doubles its Shiftly spend without a new sales cycle.

This pricing model connects directly to the Year 5 target of 8,770 total locations and users named on the Forecast slide, and to the path from $597K in Year 1 revenue to $6.5M in Year 5, an 82% five-year compound growth rate. None of those figures requires a second pricing tier or an upsell assumption to work; the model as described is a single, simple per-employee rate applied at growing scale.

The $6 figure and the per-location billing structure are both stated directly by the client as the operative pricing model today. Whether this rate holds as the product adds fair-scheduling-law compliance tooling or additional integrations, both flagged on the Roadmap slide, is not addressed in this memo and should be confirmed before this figure is used in any external pricing conversation.

One further point worth stating: because the fee is per scheduled employee rather than per manager or per site, gross revenue moves with headcount volatility inside a location, not just with locations signed. A chain with heavy seasonal staffing should show some quarter-to-quarter variance under this model even with zero new locations added, a normal feature of the pricing structure and not a churn signal on its own.

The go-to-market motion has four parts, and they are sequenced to compound rather than to run in parallel as separate bets. The core motion is direct sales to regional multi-location chains of 10 to 100 locations, a band chosen because it is large enough to matter on revenue per deal at $6 per scheduled employee per location, but small enough to avoid the long, multi-stakeholder procurement cycles typical of true enterprise accounts. Layered on top of direct sales are POS and payroll partnerships, which serve two functions at once: they are the technical dependency the product needs, as described on the Product slide, and they are a distribution channel, since a partner's existing chain relationships can shorten the sales cycle for a prospect that already runs that POS or payroll system. Franchise-association outreach is the third channel, targeting the associations that already aggregate the exact regional-chain buyer Shiftly is built for, which is a lower-cost way to reach many 10-to-100-location operators than one-by-one direct outreach. The fourth part, land-and-expand, is not a separate channel so much as the economic engine underneath the first three: because billing is per location, as set out on the Business Model slide, a single signed chain grows Shiftly's revenue every time that chain opens a new location or migrates a previously unmanaged location onto the platform, without requiring a new sales cycle. This is the mechanism by which a modest initial deal count turns into the Year 5 revenue and location targets described on the Forecast slide. The risk carried by this motion, long sales cycles for multi-location deals, is named directly on the Risks section of this memo rather than smoothed over here; the mitigation is proving payback at a single location inside a signed chain before expecting the account to expand, which is why land-and-expand is described as a second-stage motion built on a proven first location rather than a simultaneous, unproven bet across an entire chain. Sequenced this way, the four channels are not four independent bets an investor has to underwrite separately; direct sales generates the first proof point per account, partnerships and franchise-association outreach lower the cost of finding the next account, and land-and-expand is what turns each proven account into a compounding revenue line rather than a flat one-time contract, which is the assumption underneath the Year 1 to Year 5 growth path on the Forecast slide.

The go-to-market motion has four parts, and they are sequenced to compound rather than to run in parallel as separate bets. The core motion is direct sales to regional multi-location chains of 10 to 100 locations, a band chosen because it is large enough to matter on revenue per deal at $6 per scheduled employee per location, but small enough to avoid the long, multi-stakeholder procurement cycles typical of true enterprise accounts.

Layered on top of direct sales are POS and payroll partnerships, which serve two functions at once: they are the technical dependency the product needs, as described on the Product slide, and they are a distribution channel, since a partner's existing chain relationships can shorten the sales cycle for a prospect that already runs that POS or payroll system. Franchise-association outreach is the third channel, targeting the associations that already aggregate the exact regional-chain buyer Shiftly is built for, which is a lower-cost way to reach many 10-to-100-location operators than one-by-one direct outreach.

The fourth part, land-and-expand, is not a separate channel so much as the economic engine underneath the first three: because billing is per location, as set out on the Business Model slide, a single signed chain grows Shiftly's revenue every time that chain opens a new location or migrates a previously unmanaged location onto the platform, without requiring a new sales cycle. This is the mechanism by which a modest initial deal count turns into the Year 5 revenue and location targets described on the Forecast slide.

The risk carried by this motion, long sales cycles for multi-location deals, is named directly on the Risks section of this memo rather than smoothed over here; the mitigation is proving payback at a single location inside a signed chain before expecting the account to expand, which is why land-and-expand is described as a second-stage motion built on a proven first location rather than a simultaneous, unproven bet across an entire chain.

Sequenced this way, the four channels are not four independent bets an investor has to underwrite separately; direct sales generates the first proof point per account, partnerships and franchise-association outreach lower the cost of finding the next account, and land-and-expand is what turns each proven account into a compounding revenue line rather than a flat one-time contract, which is the assumption underneath the Year 1 to Year 5 growth path on the Forecast slide.

The founding team pairs the two capabilities this business actually needs: someone who has lived the problem from inside an operation, and someone who has built the specific technical engine the solution depends on. The Founder and CEO was previously the regional operations director for a 120-location restaurant group, which means the Problem slide's description of spreadsheet scheduling and invisible labor cost until payroll runs is drawn from direct, first-hand operating experience managing exactly that scale of multi-location hourly workforce, not from outside research. The Co-founder and CTO built the forecasting engine at a workforce-analytics startup that was acquired in 2023, which is the direct technical precedent for the demand-forecasting capability described on the Solution, Product, and How It Works slides. This is a meaningful point for an investor to weigh: the hardest part of Shiftly's product, turning POS and foot-traffic data into an hourly demand forecast accurate enough to auto-build a schedule against a labor-cost target, is not a first attempt by this team, it is a second build of a capability the CTO has already shipped and sold once before. Together, the pairing maps directly onto the two failure modes named on the Problem slide: the CEO's operating background explains why the product targets the manager's cost-visibility gap specifically rather than a generic scheduling calendar, and the CTO's forecasting background explains why the product leads with forecast accuracy rather than treating it as a downstream feature. Neither strength substitutes for the other; a forecasting engine without an operator who has run 120 locations risks building a model nobody in the field trusts, and an operator without a forecasting engineer cannot build the auto-scheduling core at all. Both backgrounds are stated as supplied directly by the client. The name of the workforce-analytics startup and the specific terms of its 2023 acquisition are not detailed in this memo and should be confirmed and cited before the team slide is used in external diligence materials. For an investor, the team slide is where the earlier slides' credibility is tested most directly: the Problem slide's description of spreadsheet-driven scheduling failure and the Solution slide's forecast-first mechanism are only as trustworthy as the operating and technical experience behind them, and this founding pair is the reason those two slides read as lived experience rather than as market research assembled from the outside.

The founding team pairs the two capabilities this business actually needs: someone who has lived the problem from inside an operation, and someone who has built the specific technical engine the solution depends on. The Founder and CEO was previously the regional operations director for a 120-location restaurant group, which means the Problem slide's description of spreadsheet scheduling and invisible labor cost until payroll runs is drawn from direct, first-hand operating experience managing exactly that scale of multi-location hourly workforce, not from outside research.

The Co-founder and CTO built the forecasting engine at a workforce-analytics startup that was acquired in 2023, which is the direct technical precedent for the demand-forecasting capability described on the Solution, Product, and How It Works slides. This is a meaningful point for an investor to weigh: the hardest part of Shiftly's product, turning POS and foot-traffic data into an hourly demand forecast accurate enough to auto-build a schedule against a labor-cost target, is not a first attempt by this team, it is a second build of a capability the CTO has already shipped and sold once before.

Together, the pairing maps directly onto the two failure modes named on the Problem slide: the CEO's operating background explains why the product targets the manager's cost-visibility gap specifically rather than a generic scheduling calendar, and the CTO's forecasting background explains why the product leads with forecast accuracy rather than treating it as a downstream feature. Neither strength substitutes for the other; a forecasting engine without an operator who has run 120 locations risks building a model nobody in the field trusts, and an operator without a forecasting engineer cannot build the auto-scheduling core at all.

Both backgrounds are stated as supplied directly by the client. The name of the workforce-analytics startup and the specific terms of its 2023 acquisition are not detailed in this memo and should be confirmed and cited before the team slide is used in external diligence materials.

For an investor, the team slide is where the earlier slides' credibility is tested most directly: the Problem slide's description of spreadsheet-driven scheduling failure and the Solution slide's forecast-first mechanism are only as trustworthy as the operating and technical experience behind them, and this founding pair is the reason those two slides read as lived experience rather than as market research assembled from the outside.

This slide positions Shiftly against three distinct categories of alternative, deliberately including the one most operators are actually using today rather than only naming software competitors. The first category is legacy calendar-first scheduling tools, which publish a roster well but carry no forecasting layer, so a manager using one still cannot see labor cost against forecasted sales before a shift is worked. The second is payroll-suite bolt-on scheduling, scheduling features attached to a payroll platform as a secondary module, which inherits the payroll data but was not designed around a forecast-first workflow and so still leaves the manager building a draft first and discovering the cost second. The third category, and the one named explicitly as the real incumbent, is spreadsheets and paper. This matters for how the competitive slide should be read: Shiftly's primary competitive battle is not winning share from another scheduling vendor, it is winning conversion from no purpose-built software at all, which is consistent with the Market slide's framing of 80 million-plus hourly workers currently scheduled without purpose-built software. Shiftly's edge against all three is stated as a single combination no named competitor currently offers together: forecast-first scheduling paired with a live labor-cost-to-sales view. Calendar-first tools have neither the forecast nor the live cost view; payroll-suite bolt-ons have payroll data but not a forecast-first design; spreadsheets have neither and no live view of anything. This combination is the same mechanism described on the Solution and How It Works slides, so the competitive claim and the product claim are the same claim viewed from two angles, not two separate assertions. The risk this framing does not resolve on its own, that an incumbent payroll suite could bolt on forecasting rather than staying a pure scheduling module, is named directly in the Risks section of this memo rather than dismissed here, and Shiftly's mitigation is speed of land-and-expand adoption within its target segment before that bolt-on threat materializes at scale. For a diligence reader, the useful question here is not who Shiftly's biggest software competitor is, but how long Shiftly has before a payroll incumbent already inside these same accounts decides forecasting is worth building. The Team and Go To Market slides are this memo's answer: an engineer who has shipped this capability once already, and a sales motion built to convert accounts before that answer changes.

This slide positions Shiftly against three distinct categories of alternative, deliberately including the one most operators are actually using today rather than only naming software competitors. The first category is legacy calendar-first scheduling tools, which publish a roster well but carry no forecasting layer, so a manager using one still cannot see labor cost against forecasted sales before a shift is worked. The second is payroll-suite bolt-on scheduling, scheduling features attached to a payroll platform as a secondary module, which inherits the payroll data but was not designed around a forecast-first workflow and so still leaves the manager building a draft first and discovering the cost second.

The third category, and the one named explicitly as the real incumbent, is spreadsheets and paper. This matters for how the competitive slide should be read: Shiftly's primary competitive battle is not winning share from another scheduling vendor, it is winning conversion from no purpose-built software at all, which is consistent with the Market slide's framing of 80 million-plus hourly workers currently scheduled without purpose-built software.

Shiftly's edge against all three is stated as a single combination no named competitor currently offers together: forecast-first scheduling paired with a live labor-cost-to-sales view. Calendar-first tools have neither the forecast nor the live cost view; payroll-suite bolt-ons have payroll data but not a forecast-first design; spreadsheets have neither and no live view of anything. This combination is the same mechanism described on the Solution and How It Works slides, so the competitive claim and the product claim are the same claim viewed from two angles, not two separate assertions.

The risk this framing does not resolve on its own, that an incumbent payroll suite could bolt on forecasting rather than staying a pure scheduling module, is named directly in the Risks section of this memo rather than dismissed here, and Shiftly's mitigation is speed of land-and-expand adoption within its target segment before that bolt-on threat materializes at scale.

For a diligence reader, the useful question here is not who Shiftly's biggest software competitor is, but how long Shiftly has before a payroll incumbent already inside these same accounts decides forecasting is worth building. The Team and Go To Market slides are this memo's answer: an engineer who has shipped this capability once already, and a sales motion built to convert accounts before that answer changes.

The roadmap slide exists to answer a question the rest of this memo raises but does not settle: which parts of the product described on the Product and Features slides are live today, and what is planned on top of that base as the company scales toward the Year 5 targets on the Forecast slide. The core loop, POS and foot-traffic forecasting, auto-scheduling to a labor-cost target, the live cost-versus-sales view, manager approvals, and the worker app's swap, availability, and pay-to-date features, is treated throughout this memo as live today, consistent with how the client described it. Beyond that base, the roadmap's priorities follow directly from the two structural forces named on the Why Now slide. As fair-scheduling laws continue expanding city by city, compliance tooling, automated advance-notice and change-pay calculations built into the same schedule the manager already approves, is a logical near-term addition, since it turns a growing regulatory burden into a feature the product already has the data to support. As POS and payroll platforms continue opening data access, broader integration coverage extends the addressable base of chains Shiftly can onboard without custom integration work, which is a direct input to how fast the Go To Market motion's land-and-expand assumption can scale toward the 8,770 total locations and users targeted in Year 5. The roadmap also has to be read against the use-of-funds split on the Ask slide, 60% of the $1.5M raise to product and engineering, since that allocation is the funding mechanism for whatever sits on this roadmap beyond the current live product. A roadmap item not fundable within that 60% allocation and the 24-month runway implied by the two-raise plan should be treated as a later-stage priority, not a near-term commitment. Specific roadmap dates and feature sequencing beyond the two priorities named above, compliance tooling and integration breadth, were not detailed in the brief this memo is built from and should be confirmed directly with the founding team before being presented as a fixed timeline to investors. What can be stated with confidence is the order of priority: keep the live core loop reliable across a growing base of chains first, then layer compliance and integration breadth on top, rather than chasing new feature categories before the current product is proven at the scale the Forecast slide's Year 5 targets imply.

The roadmap slide exists to answer a question the rest of this memo raises but does not settle: which parts of the product described on the Product and Features slides are live today, and what is planned on top of that base as the company scales toward the Year 5 targets on the Forecast slide. The core loop, POS and foot-traffic forecasting, auto-scheduling to a labor-cost target, the live cost-versus-sales view, manager approvals, and the worker app's swap, availability, and pay-to-date features, is treated throughout this memo as live today, consistent with how the client described it.

Beyond that base, the roadmap's priorities follow directly from the two structural forces named on the Why Now slide. As fair-scheduling laws continue expanding city by city, compliance tooling, automated advance-notice and change-pay calculations built into the same schedule the manager already approves, is a logical near-term addition, since it turns a growing regulatory burden into a feature the product already has the data to support. As POS and payroll platforms continue opening data access, broader integration coverage extends the addressable base of chains Shiftly can onboard without custom integration work, which is a direct input to how fast the Go To Market motion's land-and-expand assumption can scale toward the 8,770 total locations and users targeted in Year 5.

The roadmap also has to be read against the use-of-funds split on the Ask slide, 60% of the $1.5M raise to product and engineering, since that allocation is the funding mechanism for whatever sits on this roadmap beyond the current live product. A roadmap item not fundable within that 60% allocation and the 24-month runway implied by the two-raise plan should be treated as a later-stage priority, not a near-term commitment.

Specific roadmap dates and feature sequencing beyond the two priorities named above, compliance tooling and integration breadth, were not detailed in the brief this memo is built from and should be confirmed directly with the founding team before being presented as a fixed timeline to investors.

What can be stated with confidence is the order of priority: keep the live core loop reliable across a growing base of chains first, then layer compliance and integration breadth on top, rather than chasing new feature categories before the current product is proven at the scale the Forecast slide's Year 5 targets imply.

The financial forecast carries five numbers an investor should hold in their head together, since each depends on the others. Revenue grows from $597K in Year 1 to $6.5M in Year 5, an 82% five-year compound annual growth rate, driven by the $6-per-scheduled-employee, per-location pricing described on the Business Model slide applied against a growing base of signed chains and their expanding location counts. By Year 5, that growth curve implies 8,770 total locations and users on the platform, the denominator behind the $6.5M revenue figure. Profitability follows revenue with a lag typical of a land-and-expand SaaS model: Year 5 EBITDA reaches $2.8M at a 43% margin, meaning the business is expected to convert less than half of revenue to EBITDA even at scale, consistent with continued investment in sales, partnerships, and product through the growth window rather than a mature, cost-optimized cost base by Year 5. Readers should treat the 43% margin as a Year 5 endpoint, not an average across the full five-year path, since earlier years necessarily carry lower or negative margin while the fixed cost of the sales motion and the engineering team is absorbed by a smaller revenue base. The forecast also carries a specific cash-runway data point worth flagging on its own: minimum cash position of $68,263 occurs around month 20, which is tight enough that it is the direct justification for the two-raise structure on the Ask slide, totaling $1.5M across the first 24 months, rather than a single upfront raise. A reader should treat month 20 as the point in this plan with the least room for execution slippage, and should read the Ask slide's use-of-funds split with that constraint specifically in mind. All five figures, the Year 1 and Year 5 revenue, the 82% CAGR, the Year 5 EBITDA and margin, the month-20 minimum cash position, and the Year 5 location and user count, are modeled outputs from the client's financial model rather than independent projections built for this memo, and they are carried here exactly as the model states them. Read as a single narrative, the forecast says the business gets tight before it gets comfortable: the month-20 cash floor comes well before the Year 5 margin expansion, so the near-term execution priorities on the Go To Market and Roadmap slides matter more to this model's success than the long-run margin figure does.

The financial forecast carries five numbers an investor should hold in their head together, since each depends on the others. Revenue grows from $597K in Year 1 to $6.5M in Year 5, an 82% five-year compound annual growth rate, driven by the $6-per-scheduled-employee, per-location pricing described on the Business Model slide applied against a growing base of signed chains and their expanding location counts. By Year 5, that growth curve implies 8,770 total locations and users on the platform, the denominator behind the $6.5M revenue figure.

Profitability follows revenue with a lag typical of a land-and-expand SaaS model: Year 5 EBITDA reaches $2.8M at a 43% margin, meaning the business is expected to convert less than half of revenue to EBITDA even at scale, consistent with continued investment in sales, partnerships, and product through the growth window rather than a mature, cost-optimized cost base by Year 5. Readers should treat the 43% margin as a Year 5 endpoint, not an average across the full five-year path, since earlier years necessarily carry lower or negative margin while the fixed cost of the sales motion and the engineering team is absorbed by a smaller revenue base.

The forecast also carries a specific cash-runway data point worth flagging on its own: minimum cash position of $68,263 occurs around month 20, which is tight enough that it is the direct justification for the two-raise structure on the Ask slide, totaling $1.5M across the first 24 months, rather than a single upfront raise. A reader should treat month 20 as the point in this plan with the least room for execution slippage, and should read the Ask slide's use-of-funds split with that constraint specifically in mind.

All five figures, the Year 1 and Year 5 revenue, the 82% CAGR, the Year 5 EBITDA and margin, the month-20 minimum cash position, and the Year 5 location and user count, are modeled outputs from the client's financial model rather than independent projections built for this memo, and they are carried here exactly as the model states them.

Read as a single narrative, the forecast says the business gets tight before it gets comfortable: the month-20 cash floor comes well before the Year 5 margin expansion, so the near-term execution priorities on the Go To Market and Roadmap slides matter more to this model's success than the long-run margin figure does.

Shiftly is raising $1.5M in seed funding across two tranches inside the first 24 months, a structure set directly by the cash-runway data on the Forecast slide, where minimum cash falls to $68,263 around month 20. The first tranche is priced at a $21.4M pre-money valuation on a $1.0M raise, representing 4.45% dilution, the valuation the rest of the $1.5M program is anchored to; the second tranche completes the $1.5M total within the 24-month window rather than being raised as a separate, later round with its own new price. That $21.4M pre-money figure is a blended output of five valuation methods across three weighted groups rather than a single method or a negotiated number. Internal methods carry 50% of the weight, split evenly between Berkus (25%) and Risk Factor Summation (25%), both of which score the business on qualitative execution and risk factors rather than market comparables. External methods carry 40%, split evenly between Scorecard (20%) and Venture Capital method (20%), which benchmark Shiftly against comparable seed-stage companies and expected return multiples. Future cash-flow methods carry the remaining 10%, split evenly between DCF (5%) and First Chicago (5%), which discount the Year 1 to Year 5 forecast on the Forecast slide back to present value under different scenario weightings. The heavier weighting toward internal and external qualitative methods, 90% combined, over pure cash-flow modeling reflects that Shiftly is still earlier than the stage at which a five-year forecast alone should carry most of the valuation weight. The use of funds is 60% product and engineering, 25% sales and partnerships, and 15% operations and working capital. That split funds the roadmap priorities named on the Roadmap slide first, then the direct-sales and POS/payroll-partnership motion described on the Go To Market slide, with the smallest share reserved for the operating buffer that keeps the business above the month-20 minimum cash point. For an investor, the sizing question this slide answers is not just "how much" but "why this much, priced this way": the two-tranche $1.5M structure matches the cash-runway math on the Forecast slide rather than an arbitrary round size, and the $21.4M pre-money is a blended figure an investor can pull apart method by method rather than a single comparable pulled from a market survey.

Shiftly is raising $1.5M in seed funding across two tranches inside the first 24 months, a structure set directly by the cash-runway data on the Forecast slide, where minimum cash falls to $68,263 around month 20. The first tranche is priced at a $21.4M pre-money valuation on a $1.0M raise, representing 4.45% dilution, the valuation the rest of the $1.5M program is anchored to; the second tranche completes the $1.5M total within the 24-month window rather than being raised as a separate, later round with its own new price.

That $21.4M pre-money figure is a blended output of five valuation methods across three weighted groups rather than a single method or a negotiated number. Internal methods carry 50% of the weight, split evenly between Berkus (25%) and Risk Factor Summation (25%), both of which score the business on qualitative execution and risk factors rather than market comparables. External methods carry 40%, split evenly between Scorecard (20%) and Venture Capital method (20%), which benchmark Shiftly against comparable seed-stage companies and expected return multiples. Future cash-flow methods carry the remaining 10%, split evenly between DCF (5%) and First Chicago (5%), which discount the Year 1 to Year 5 forecast on the Forecast slide back to present value under different scenario weightings. The heavier weighting toward internal and external qualitative methods, 90% combined, over pure cash-flow modeling reflects that Shiftly is still earlier than the stage at which a five-year forecast alone should carry most of the valuation weight.

The use of funds is 60% product and engineering, 25% sales and partnerships, and 15% operations and working capital. That split funds the roadmap priorities named on the Roadmap slide first, then the direct-sales and POS/payroll-partnership motion described on the Go To Market slide, with the smallest share reserved for the operating buffer that keeps the business above the month-20 minimum cash point.

For an investor, the sizing question this slide answers is not just "how much" but "why this much, priced this way": the two-tranche $1.5M structure matches the cash-runway math on the Forecast slide rather than an arbitrary round size, and the $21.4M pre-money is a blended figure an investor can pull apart method by method rather than a single comparable pulled from a market survey.