LuxHub DIALux freelance Open Quotes: how should you set price and delivery time?

The short answer: quote the reviewed scope, then propose a delivery time you control

For an Open Quote project, an eligible DIALux freelancer should inspect the technical brief, supplied materials, customer budget, expected effort, deadline and revision conditions before proposing a price and delivery time. The budget is a constraint to evaluate, not an instruction to underprice unknown work, and a proposal is not the same as accepting a Fixed Bounty mission.

LuxHub's current public specialist portal is a fictional English-only demo. It shows sample Fixed Bounty-style missions with scope, inputs, effort, deadline and illustrated net payout, but it does not demonstrate a live Open Quote submission screen. The Open Quote flow described here is therefore an intended production workflow and decision framework, not evidence that real projects or proposal functions are currently available.

Separate an Open Quote from a Fixed Bounty before pricing

A Fixed Bounty project presents a stated price that an eligible specialist may accept only after reviewing the preview. An Open Quote project presents a customer budget or commercial reference and asks the eligible specialist to propose a price and proposed delivery time. Not every project should offer both routes, and submitting a proposal should not reserve or accept the work automatically.

This distinction matters because the decision is different. A Fixed Bounty review asks whether the locked scope, amount and deadline are workable. An Open Quote review asks what price and schedule are justified by the supplied information. The production interface should label the model clearly before the freelancer enters any response.

Build the price from the actual DIALux effort

Estimate each stage: checking drawings and IES or LDT files, preparing geometry, placing luminaires, configuring calculation surfaces, running and reviewing results, assembling the report, answering technical clarification, completing QA and handling the stated revision allowance. Add time for complex imports, missing dimensions, several operating scenes or unusually detailed outputs.

An expected-effort label can help frame the project, but it is not a command. Compare it with your own method and experience. If the preview lacks a critical input, use the protected clarification route before quoting or state an assumption that the customer can evaluate. A low number built on silent assumptions is not a reliable match to the budget.

Use the customer budget as a fit test

When the full reviewed scope can be delivered responsibly within the customer's budget, the freelancer can propose a matching price. The proposal should still identify the output and delivery basis so the customer can understand what the amount covers. Matching a budget does not mean adding unrequested work or removing required checks to make the figure fit.

If your efficient workflow supports a lower amount, the proposal can reflect that efficiency without treating price as the only differentiator. If the necessary scope cannot be delivered within budget, do not disguise the mismatch. Clarify the required outcome, narrow an optional element with the customer's agreement, justify a different proposal where the workflow permits it, or decline.

Propose delivery time from capacity, time zone and dependencies

The freelancer-controlled delivery time should include modelling, calculation, report preparation, internal QA and the agreed revision allowance. It should also reflect current capacity. A short technical task can still need several calendar days when source files, clarification or customer confirmation are dependencies.

Read the requested deadline and its time zone before proposing. State whether the delivery time begins at project confirmation, file release or clarification closure. For remote work, this prevents a proposal made in one country from being interpreted against an unstated end-of-day in another.

A complete preview should come before the proposal form

The production project preview should show the outcome, scope, supplied files or material summary, customer budget, expected effort, deadline, relevant standard, revision allowance and QA requirements before the specialist can propose. The freelancer should be able to leave the preview and decline unsuitable work without a bidding penalty.

LuxHub may email an approved freelancer when a compatible project matches the freelancer's skills, work preferences and availability. That email is an alert and entry point, not the whole project experience. It should lead to the relevant first-party board or protected preview. Approved specialists should also be able to browse compatible projects on the private board without waiting for email.

Keep the response model accurate after submission

An Open Quote remains a proposal until the customer or controlled selection workflow chooses it and the project is confirmed. The system should preserve the proposed price, proposed delivery time, assumptions and scope basis in the project record. If a material change is approved later, the adjustment should be recorded rather than replaced by an informal message.

The public demo does not prove that this proposal, selection or adjustment workflow is production-enabled. LuxHub should verify permissions, notifications, scope locking and settlement behavior before presenting those controls as live. Joining LuxHub does not guarantee approval, projects, selection, income or immediate work.

A United Kingdom freelancer should make worldwide timing and currency explicit

A DIALux freelancer working remotely from the United Kingdom should convert the stated project deadline to local time, note any daylight-saving offset and identify the hours available for clarification with a worldwide customer. Confirm the reporting language, software version, governing criteria, file-access window and whether a USD-denominated project record will require separate local accounting or payout checks.

Do not infer UK demand, eligibility or payout availability from this example. Check the current onboarding and commercial terms that apply to the account before committing. The practical proposal is the one supported by a complete brief, realistic capacity and an explicit delivery basis.

A quick decision check before you join

1. 01
   Confirm the response model

   Verify that the project is an Open Quote rather than a Fixed Bounty before entering a price or schedule.

2. 02
   Review the technical package

   Check geometry, photometry, criteria, outputs, effort, deadline, QA and revision conditions.

3. 03
   Estimate your real effort

   Include modelling, calculation, reporting, clarification, quality review and delivery administration.

4. 04
   Test the customer budget

   Match it only when the complete required outcome can be delivered responsibly at that amount.

5. 05
   Set a controlled delivery time

   Base the proposal on capacity, dependencies, time zone and the point at which the clock starts.

6. 06
   Record assumptions or decline

   Make dependencies visible and do not propose when scope, competence, confidentiality or capacity remains unsuitable.