Requirements
can be converted into acceptance criteria and aligned with business objectives
Digital Product Solutions
Your product journey needs a partner, not an outsourcing vendor
From strategic planning to operations and maintenance, the eight stages can be taken on separately. For each stage, acceptance-ready documents are delivered, and billing is based on actual hours throughout.
Teleworker helps teams that need to build their own systems or digital products: from strategic planning, service process and requirements definition, product prototyping, feasibility analysis, system design and development, testing and validation, and product launch to operations and maintenance, the eight stages can be taken on separately. For each stage, an execution item list, estimated hours, and a scheduling worksheet are delivered. Billing is based on actual hours throughout, and no fixed monthly fee is charged for operations and maintenance. The technical scope includes React, React Native, Vue, and Python.
The problem is not that it cannot be built, but that what is built is not what is needed
Most failed digital product projects are technically completed.
The real breaking point happens earlier: what the client says is treated as requirements and work starts directly.
We define these two things separately:
Expectations
unconfirmed, not documented in writing, and cannot be converted into acceptance criteria
There is nothing wrong with expectations; every project starts with a pile of expectations. What is wrong is skipping the translation step and going straight into development — after completion, both sides insist on their own interpretation, and then the argument begins: “Wasn’t this supposed to be included?”
Our work starts with translating expectations into requirements. If something cannot be written as acceptance criteria, we will not let it enter development.
Four mechanisms
- 1
Phased engagement
Eight stages: strategic planning, service process and requirements definition, product prototype, feasibility analysis, system design and development, testing and validation, product launch, operations and maintenance.
You do not need to take on everything at once. You can do only the upfront strategy and requirements definition, then use the documents to outsource the work yourself; you can also take on only the mid-to-late-stage development and testing.
- 1Strategic planning
- 2Service process and requirements definition
- 3Product prototype
- 4Feasibility analysis
- 5System design and development
- 6Testing and validation
- 7Product launch
- 8Operations and maintenance
- 2
Every item can be verified
There are clear standards for writing acceptance items — they must be verifiable by another person without having to guess the intent:
❌ Not accepted ✅ Write it this way ❌ Not acceptedThe feature works normally ✅ Write it this wayWhen an invalid promo code is entered, “Invalid promo code” is displayed, and the checkout button remains disabled ❌ Not acceptedThe UI is fine ✅ Write it this wayThe form error message is displayed below the field, and the field border turns red ❌ Not acceptedLooks OK ✅ Write it this wayThe API response format complies with the definition in Section 3 of the specification document Each item covers five states: normal, boundary, error, empty value, and permissions.
- 3
Billed by actual hours worked, operations and maintenance included
Development is billed by actual hours worked. Operations and maintenance after launch are not charged as a fixed monthly fee — only hours actually performed are billed, and months with no maintenance needs are zero.
- 4
View progress directly, not through weekly reports
Clients can directly access the project’s Monday.com board — the status, estimated hours, actual hours, and acceptance items for each task are visible to you at any time.
The prerequisite for billing based on actual hours is that the hours must be verifiable. We do not use weekly reports to summarise your project progress, because weekly reports are a processed version; the board is the raw version.
You know what needs to be done and how long it will take before work begins
Regardless of which stages we take on, we provide:
| Deliverables | Content |
|---|---|
| DeliverablesList of execution items | ContentSpecific work items broken down into estimable sizes, each with acceptance criteria |
| DeliverablesEstimated hours | ContentEstimated effort for each item, so the total scope is visible before work begins |
| DeliverablesScheduling worksheet | ContentA schedule arranged according to available working hours, for you to review and adjust |
| DeliverablesEnvironment and delivery instructions | ContentProject completion requirements, including deployment and environment configuration instructions |
Execution items, estimated hours, and the scheduling worksheet will all be provided to you for review and adjustment; they are not decided unilaterally by us and then communicated to you.
Environment and handover documentation are closeout requirements, not add-on services. Without them, the project is not considered finished — this means you can hand the product over to another team at any time without being locked in.
Collaboration model and pricing
Estimate the time first, then decide whether to proceed
| Item | Cost |
|---|---|
| ItemSystem development time estimate and quotation | CostNT$21,200 / engagement |
We will assess the system scale, complexity and workload based on your initial requirements, and produce a written workload estimate and quotation.
If you confirm the development work within 30 days after the quotation is delivered, this fee will be fully credited against the development fee. In other words, as long as you decide to proceed, the time estimate is effectively free; if you do not proceed, you still take away a complete estimate that you can use for price comparisons.
Hourly Rates
| Item | Rate |
|---|---|
| ItemRequirements interviews and specification documents | RateNT$3,800/hour |
| ItemUI and page design | RateNT$3,800/hour |
| ItemFront-end development | RateNT$3,030 per hour |
| ItemBack-end development | RateNT$3,030 per hour |
| ItemIntegration testing | RateNT$3,030 per hour |
| ItemConsulting services | RateNT$6,700 per hour |
| ItemOperations and maintenance | RateBased on actual hours worked, the corresponding rates listed above apply,no fixed monthly fee |
The above are the rates for 2026, in New Taiwan dollars and excluding tax.
Requirements interviews and specification documents are formal work items themselves and will be counted as working hours. We do not treat them as free pre-sales — because how well that part is done determines everything that follows.
Project scale reference
We recommend dividing the project into Phases, with each Phase lasting about 2–3 months and a cost scale of about NT$60–70 萬. Actual costs are determined based on the estimated working hours after the tasks have been broken down.
Team setup
Depending on the project scale, the team may include a Consultant, project management, frontend, backend, architect, animator, and UI/UX designer.
How should I estimate the budget?
The trade-off of billing based on actual working hours is clear: you cannot know the total price at the moment of signing the contract.
Our approach is:
- Break tasks down to an estimable size; 1–4 hours is ideal, and anything over 8 hours must be broken down further
- Every task has an estimated number of hours, so you can see the total volume before work begins
- Estimation deviations follow clear standards: ±20% is normal, ±50% requires an explanation, and over 100% will lead us to review the breakdown approach
- Early warnings are better than explanations after the fact: when a deviation is identified, we inform you immediately and update the schedule, rather than waiting until the delivery date to say so
Fixed quotes hide the risk inside the quote; what you pay is a risk premium. Billing by actual hours brings the risk out into the open for discussion; what you pay for is what actually happens.
Technical scope
We focus on React, React Native, Vue and Python, covering Web, App, backend and data application development; we do not pursue breadth in the technology stack, but go deep enough in the areas we know well.
Suitable for
- Organisations whose requirements are not yet fully defined and need someone to help think them through
- Companies with an internal team that need to supplement a specific phase or specific role
- Products whose maintenance needs after launch are not fixed and that do not want to pay idle monthly fees
- Organisations that value handover documentation and transferability
- Clients who want to see project progress directly rather than receive curated weekly reports
Not suitable for
- Procurement processes that require the total price to be fixed at the time of contract signing
- Projects whose specified technology stack is outside the scope of React, React Native, Vue and Python
- Projects with fully defined specifications that only need implementation at the lowest price
Frequently Asked Questions
Can digital product development cover only some of the stages?
Yes.... [Read full content]
Digital products are billed based on actual working hours. How can the budget be controlled?
Before work starts, you will receive a list of execution items, estimated hours, and a scheduling worksheet, which you can review and adjust.... [Read full content]
Is there an additional fee for time and cost estimation for digital products?
Yes, NT$21,200 per project.... [Read full content]
Is there really no monthly fee for the maintenance and operation of digital products?
No.... [Read full content]
Which technologies do you use for digital product development?
React, React Native, Vue and Python.... [Read full content]
First, clarify what needs to be done
In the first interview, we will clarify three things: the business problem you want to solve, the current state of your organisation and technology, and which expectations have not yet been translated into requirements. The conclusions from this interview will determine which stage you need to start from.
Book a requirements interview