A delivery window is the one number most service businesses keep private. You will publish your logo, your portfolio, sometimes even your prices, but the schedule stays in the proposal, where it can be hedged and quietly renegotiated. Putting a timeline on the public page does the opposite of hedging. It is a commitment made before the first call, and it decides who bothers to make that call.
Devign, a digital agency that works across Lebanon and the United States, takes this route. Its site does not just list services, it attaches windows to them: a website in two to six weeks, a custom CRM or business system in four to twelve, a mobile app in six to sixteen. The company describes itself as remote-first, with a presence in Casper, Wyoming and in Lebanon, and a focus on clients across the MENA region. The specific durations matter less than the decision to print them at all.
A number on the page is a filter
The first thing a published timeline does is sort your inbound. A founder who needs a marketing site live before a launch reads “two to six weeks” and self-selects in. A client who wants an open-ended build with no fixed end reads the same line and self-selects out. You have done qualification before anyone fills in a form. That is unglamorous lead generation, and it is more honest than a discovery call that exists mostly to discover whether the budget is real.
The second thing it does is point pressure inward. You cannot advertise a six-to-sixteen-week app if every app starts from a blank repository and an open argument about frameworks. The promise only survives if the work behind it is repeatable. So the timeline forces the productization: a default stack, a default architecture, a set of decisions already made. Devign lists the tools it standardizes on, React Native and Flutter for mobile, Laravel and Node.js behind the API, and a published delivery window is the customer-facing shadow of that standardization.
The productized service underneath
This is why the timeline and the service menu belong together. Devign splits its work into five divisions: web, business systems, mobile apps, a TikTok agency arm focused on creator management, and social media production. Each division is a bounded offer with a known shape, which is exactly what makes a delivery window possible to quote. The opposite posture, “we do whatever you need,” is the one that cannot promise a date, because nothing about it is repeatable.
We are describing the productized-service playbook, the move from selling hours to selling a defined outcome with a defined edge. The published timeline is the sharpest expression of it. A range like four to twelve weeks is wide enough to absorb real variation and narrow enough to mean something. It says, in effect, we have done this often enough to know the distribution.
A range like four to twelve weeks is wide enough to absorb real variation and narrow enough to mean something.
The structure is part of the offer
There is a second commitment hiding on that page, and it is jurisdictional. Running remote-first from both Lebanon and Wyoming is itself a productized answer to a question every cross-border client eventually asks: who am I actually contracting with, and under whose law. We have written before about why MENA founders register US entities, and an agency that serves the region from a US footing has turned that structural answer into part of the pitch. A client in the Gulf or in Europe sees a US presence and reads it as reduced friction on payment, contract, and recourse.
None of this requires the durations to be correct to the day. Schedules slip, scopes change, and a public window is a target rather than a guarantee. The point is what printing the target does to the business that prints it.
The takeaway is the forcing function
If you run a service business, the lesson is not to copy two-to-six weeks onto your homepage tomorrow. The lesson is that the number comes last and changes everything before it. You cannot publish a window you have not earned with a repeatable process, so the act of committing to one in public drags the rest of the operation toward standardization. You define the default project, you name the default stack, you decide what you will not do.
Most teams want the process first and the promise later, once everything is tidy. It usually runs in the other direction. Make the promise specific, in public, and the process has to follow. The timeline on the page is not a description of how you work. It is the thing that forces you to work that way.