Questions & answers.

Why is there a monthly development fee? Can't we use milestone billing instead?

Software is a moving target. What appears to be the right solution on day one will evolve as we test workflows, put designs in front of users, connect third-party services, and learn from real customer and contractor behavior.

A fixed-price milestone model works best when every requirement can be specified in advance and is unlikely to change. For a new platform, it can create the wrong incentives: the client is forced to defend an early specification, while the developer is rewarded for restricting changes. The monthly model reserves a senior team for DwellOne and lets us continually direct that capacity toward the work creating the most value. Quarterly evaluation points provide the accountability to review what was delivered and agree what comes next.

Why is the development fee $25,000 per month?

The fee is for an ongoing product and technology capability, not simply hours spent writing code. Lee Benson and Jeff La Croix will work directly on DwellOne's product, supported by any specialists Uplevel engages and manages. The work spans product design, native iOS and Android development, the staff dashboard, cloud infrastructure, payments, AI-assisted workflows, testing, release management, monitoring, and support.

Building the same capability internally would normally require several disciplines, recruiting time, management overhead, and long-term employment commitments. The monthly fee gives DwellOne one accountable partner and a team that can flex with the priorities of the product.

Why is there a 2.5% platform fee?

We want our incentives to remain aligned after launch. A platform fee means we benefit when the system helps DwellOne win more work, convert more quotes, process more business, and expand into new markets. It gives us a continuing reason to prioritize improvements that create measurable commercial value—not just features that are interesting to build.

In simple terms, we earn together. When DwellOne's processed volume increases, everyone wins; when it does not, our variable compensation does not increase.

Aren't we paying twice—once for development and again through the platform fee?

The two fees serve different purposes. The monthly fee pays for the team actively designing, building, releasing, maintaining, and improving the platform. The platform fee is the variable part of the partnership and ties our economics to the value flowing through the product.

Without a development fee, the delivery team would be expected to finance a substantial build with no control over DwellOne's sales, marketing, contractor capacity, or adoption. Without a platform fee, Uplevel would be paid the same whether the product materially grew the business or merely shipped. The combination shares risk more fairly and keeps both parties focused on adoption and revenue.

Exactly what does the 2.5% apply to?

As proposed, it applies only to gross customer payments successfully processed through the DwellOne platform. Refunds, chargebacks, sales taxes, payment-processor fees, and payments collected outside the platform are excluded. At the proposed rate, every $1 million of qualifying processed volume produces a $25,000 platform fee.

The master services agreement should define the calculation, reporting, payment timing, treatment of unusual transactions, and audit process precisely so there is no ambiguity.

Does Uplevel earn a fee on business that never touches the platform?

No. The proposal excludes payments collected outside the platform. Our goal is to make the platform useful enough that DwellOne naturally chooses to run more business through it—not to claim a percentage of unrelated revenue.

What is included in the monthly fee, and what costs extra?

The monthly fee covers the agreed design, development, release, support, and product priorities across mobile, web, cloud, and back-office work, including any subcontractors engaged and managed by Uplevel.

Production infrastructure, app-store fees, payment-processing charges, and usage-based third-party services are separate because they scale with actual use and are charged by outside providers. Those costs will be passed through at cost where agreed in advance. Applicable taxes are also excluded.

How do we know we are receiving enough value each month?

Work will be delivered in small, reviewable increments rather than disappearing into a long build cycle. DwellOne will be able to see working software, review designs, test key journeys, and help set priorities throughout development. At each quarterly evaluation point, we will review what was delivered, what was learned, which risks remain, and what should be funded next.

The statement of work should also establish the practical operating cadence: the priority backlog, demonstrations, decision owners, status reporting, acceptance criteria, and the product and business measures we will watch.

What will we actually have after the first three months?

Milestone 1 is targeted as an initial production release of the core end-to-end journey: a customer submits a request with job context, DwellOne prepares and approves a quote, the customer accepts and pays a deposit, and the customer, contractor, and DwellOne can track and communicate about the job through completion.

It also establishes the less-visible foundation the platform needs to operate reliably: product design, customer and contractor accounts, the staff dashboard, cloud environments, payments and digital agreements, notifications, audit records, analytics, security controls, and real-device testing. The iOS and Android apps will be prepared and submitted to their respective app stores.

Is the three-month delivery date guaranteed?

It is a target, not an unconditional guarantee. Delivery depends on agreeing the final priority order at kickoff, receiving timely feedback and data from DwellOne, gaining access to the required third-party services, and completing Apple and Google review processes that neither party controls.

We will manage the date by protecting the core journey and making scope choices openly. If a dependency changes or a feature proves more complex than expected, we will bring DwellOne the tradeoff: adjust the feature, change the sequence, or change the timing. There should be no surprise at the end of the quarter.

What happens if our priorities change during development?

Priorities will change—that is one reason for the partnership model. We will maintain an agreed backlog and make the impact of each change visible. A newly urgent item can move forward, but the team will also show what moves back so that scope, quality, and timing remain honest.

Changes that fit within the team's agreed capacity do not require inventing a new commercial negotiation every time. A material expansion in team size, outside cost, or responsibility would be discussed and agreed before proceeding.

Are all the features in the proposal included in Milestone 1?

No. Milestone 1 focuses on the core request-to-completion workflow and the foundation beneath it. Items in the “After the MVP” section—such as LiDAR room modeling, a rebuilt public website, lead-generation landing pages, subscription services, phone and SMS integration, financing, and deeper NetSuite integration—are candidates for later prioritization, not commitments hidden inside the first three months.

Keeping that distinction clear protects the launch. It lets us put a coherent product into real use, learn from it, and invest next in the features with the strongest evidence behind them.

What happens after Milestone 1? Are we committing indefinitely?

Milestone 1 is intended to be the first evaluation period, not a promise to build every idea in the proposal. At the end of the quarter, we will review the product, adoption, operating impact, commercial results, and next priorities together.

The proposal anticipates a long-term partnership because software needs maintenance, security updates, platform updates, support, and continued improvement. The master services agreement should nevertheless state the notice, renewal, and termination terms clearly so DwellOne knows exactly how future commitments are made.

Why build native iOS and Android apps before a full customer-facing web experience?

The service happens in homes and in the field. Native apps provide the strongest base for guided camera capture, video, notifications, location-aware arrival updates, secure device login, offline capabilities, and later LiDAR or augmented-reality features. They also give contractors a dependable tool at the job site.

We recognize that requiring an app download can add friction for a new lead. That is why the longer-term plan includes browser-based quoting and onboarding. Initial workflows should also preserve assisted service: a customer can still speak with the DwellOne team, and staff can work from the same job record rather than forcing every customer into a single channel.

What if customers or contractors do not adopt the app?

Adoption has to be designed, not assumed. The product must save each audience time: faster requests and clearer updates for customers, organized job opportunities and schedules for contractors, and less repetitive coordination for staff. Existing contractors can be imported in bulk, and rollout can begin with a small group before expanding.

We will measure where people abandon or avoid a workflow, speak with users, and improve it. During the transition, DwellOne's team can continue assisting people by phone while recording the same work in the platform. The objective is a gradual shift to a better process, not an abrupt shutdown of the service customers already trust.

Is the goal to replace DwellOne's personal service with automation?

No. DwellOne's judgment, contractor relationships, and willingness to stand behind the work are the advantage we are protecting. Automation should handle repeatable administration—collecting information, routing updates, preparing draft actions, sending reminders, and maintaining records—so the team has more time for decisions, exceptions, quality, and customer care.

The platform is designed around human approval where judgment or risk matters. It should make DwellOne feel more attentive and consistent, not less personal.

Can we trust AI-generated estimates, matches, or answers?

AI will assist the workflow; it will not be treated as an unquestionable authority. A ballpark estimate is clearly different from a formal approved quote. Contractor suggestions can reduce the search space, but DwellOne retains control over who is approved and assigned. Routine answers can be prepared from approved job and account data, while exceptions and higher-impact decisions are escalated to staff.

We will preserve source information and audit trails where appropriate, test the system against real DwellOne scenarios, and tune the controls as we learn. The standard is not “the AI said so”; it is whether the system helps DwellOne make a faster, better-informed decision.

How will customer, contractor, payment, and location data be protected?

Milestone 1 includes separate development, staging, and production environments; role-based access; monitoring and alerting; secure handling of personal and payment data; and clear permission and consent flows. The detailed security architecture, retention periods, backup approach, incident responsibilities, and access procedures should be documented during kickoff and in the final agreements.

Location sharing is specifically limited to an agreed window around an active appointment, with explicit consent and visible controls. It is intended for arrival updates, job-time records, and operational auditing—not continuous off-hours tracking. The relevant privacy disclosures and contractor terms must explain that behavior plainly.

Will DwellOne store customers' raw card or bank details?

The preferred design is to use an established payment provider so sensitive card or bank credentials are handled within that provider's compliant systems, while the DwellOne platform keeps only the references needed to support deposits, receipts, refunds, and approved future payments. The exact provider, payment flow, saved-payment behavior, and division of compliance responsibilities will be agreed during product design.

Customers should be shown the payment terms before they authorize a transaction, and saving a payment method should remain optional.

What happens when the system goes down or something goes wrong after launch?

Reliability work is part of the product, not an afterthought. The proposal includes monitored cloud infrastructure, automated release processes, multiple environments, testing, alerting, and an auditable record of important workflow events. Those measures reduce failures and help us diagnose them quickly when they occur.

The final agreement should define the support process, severity levels, response expectations, backup and recovery approach, maintenance windows, and responsibility for third-party outages. No responsible team can promise that software will never fail; we can promise to design for resilience, make problems visible, and respond through an agreed process.

What if NetSuite or another third-party integration is harder or more expensive than expected?

Third-party systems introduce variables that cannot be controlled from the DwellOne application: API limits, licensing, documentation quality, vendor approval, and future policy changes. That is why deeper NetSuite integration is presented as a later candidate and why usage-based or vendor charges are separate from the development fee.

Before committing to an integration, we will confirm access, define the minimum useful data exchange, identify ongoing costs, and test the highest-risk assumptions. If a vendor constraint changes the plan, DwellOne will see the options and tradeoffs before additional cost is incurred.

Who is responsible for privacy policies, contractor terms, payment rules, and other legal requirements?

Uplevel will provide technical support for implementing DwellOne's approved policies and will build the agreed consent, permission, security, and recordkeeping controls. DwellOne remains the business operator and should approve its commercial rules and legal documents with appropriate counsel.

The final agreements should assign responsibilities for privacy, consumer disclosures, contractor classification and terms, payment disputes, warranties, accessibility, data requests, and regulatory changes. Technical implementation and legal approval are related, but they are not the same service.

Who owns DwellOne's data and the software we are paying to build?

DwellOne's customer, contractor, property, job, and transaction data should remain DwellOne's data. The master services agreement should also state, in plain language, the ownership and license terms for custom source code, Uplevel's pre-existing tools and reusable components, third-party software, designs, documentation, and app-store or cloud accounts.

This proposal is intentionally not the final IP agreement. We should settle those rights before development begins, including DwellOne's operating rights, Uplevel's ability to use general know-how, and the practical access each party needs to support the platform.

Why does the proposal mention a 50/50 company for spun-out IP?

The DwellOne platform may eventually have value beyond DwellOne's own operations—for example, as software offered to independent contracting firms. If both parties choose to pursue that separate opportunity, our current commercial intent is to form a new company with equal ownership so the value created by DwellOne's operating expertise and Uplevel's technology work is shared.

That company is not created by accepting this proposal, and external commercialization is not included automatically. Ownership, contributed IP, licensing, governance, funding, investor requirements, decision rights, and economics would all require a separate definitive agreement. DwellOne can evaluate that opportunity when there is evidence to support it.

What happens if the partnership ends? Are we locked in?

The platform should be built so DwellOne's business is not held hostage by an avoidable operational dependency. We favor standard technologies, documented systems, clearly assigned accounts, exportable business data, and a defined transition process.

The master services agreement should specify termination notice, final payments, ongoing platform-fee obligations if any, source-code and credential access, data export and deletion, transition assistance, third-party account ownership, and what support continues during a handover. Agreeing those terms at the beginning is the best way to make a long-term partnership a choice based on value rather than lock-in.