Power Platform Dev (Dataverse/Apps/Automate/BI/Copilot) - 58 specced requirements, detail-critical

READ THIS BEFORE YOU DO ANYTHING ELSE. Two PDFs are attached to this posting: Document A (7 pages) and Document B (23 pages). Together they are the complete scope of the work. I have written the screening questions so that they cannot be answered without having read both, and I will be able to tell within about fifteen seconds whether you did. I am not being difficult for the sake of it. A project like this fails in one specific way, and it is always the same way: a perfectly competent developer builds what a system like this normally looks like, instead of what we actually asked for. The two are close enough that the difference only surfaces at acceptance, which is the expensive place to find it. ------------------------------------------------------------ WHAT THIS IS This is an ERP build. Not a CRM, not a reporting layer, not an app on top of an existing system - the full operational backbone of a company, replacing everything it currently runs on. We are a professional services firm: consulting, audit and training work, internal staff plus external collaborators. Today the entire business runs on spreadsheets. We want one system that follows a job from the first quotation through to the final invoice and its collection, with the master data, the workflows, the authorisations and the financial control that an ERP is expected to carry. The build is on Microsoft Power Platform. Dataverse is the ERP database; Power Apps is the interface; Power Automate is the process engine; Power BI is the reporting layer. If you have built ERP or PSA systems on other stacks and have real Power Platform depth, that background is an advantage - the thinking transfers, and the failure modes you have already seen are the ones this project has. ------------------------------------------------------------ WHAT THE SYSTEM DOES Nine functional blocks: 1. QUOTATIONS AND ORDERS. Build proposals from our own document templates, keep every version and revision, record the signed acceptance, and turn an accepted quotation into a live engagement - activities, budget and billing plan - in a single step, carrying one engagement code across everything downstream. 2. ENGAGEMENT PLANNING. Engagements, sub-engagements, work packages, activities and milestones. Effort planned per person and per period, compared against real available capacity. Calendar, Gantt, Kanban and resource-load views. Versioned baselines with full revision history. 3. TIME REPORTING. Web and mobile. A weekly grid, a daily draft, an optional timer, intelligent duplication of recurring lines, and suggestions drawn from the user's calendar which the user must confirm rather than accept silently. Submission, approval, rejection with a stated reason, and period locking. 4. PROGRESS AND CONTROL. Three separate progress measures, alerts on delays and overruns with configurable severity thresholds, change requests when tolerance is exceeded, and a printable progress statement generated from a template. 5. REVENUE CYCLE. Billing plans by instalment, by progress, by date, by event, by consumption or by final balance. Unmet prerequisites shown on screen before an invoice can be authorised. Export to our existing e-invoicing system. Payment import, reconciliation, overdue tracking, reminders and credit notes. 6. SUPPLIER CYCLE. Assignments to external collaborators linked to customer engagements, external self-reporting, manager approval, automatic clearance to invoice, purchase-invoice import and matching, a payment-approval workflow and a payment schedule. 7. EXPENSES AND TRAVEL. Mileage, tolls, parking, per-diem allowances and advances, each correctly separated into company cost, employee reimbursement and rechargeable-to-customer. 8. REPORTING. Power BI dashboards for five distinct audiences, plus scheduled e-mail reports, exports and charts - not tables only. 9. A COPILOT AGENT. Eight defined use cases, from management Q&A to draft timesheet generation to progress-statement narrative. All of them read-only or requiring explicit confirmation, and all grounded strictly in data the asking user is authorised to see. Documents A and B contain the real detail. The list above is the map, not the territory. ------------------------------------------------------------ WHY THIS JOB IS HARD, AND IT IS NOT THE REASON YOU EXPECT Nothing here needs an exotic technical skill. Everything is achievable on the standard platform. What makes it hard is that we have thought about our business for a long time and hold a specific, considered preference on a very large number of small points - and almost every one of those preferences differs slightly from the obvious default. Six real examples, all taken from the attached documents: - MARGIN IS DEFINED "WRONGLY", DELIBERATELY. Document A section 3.7 defines margin as value sold minus maximum PLANNED effort, explicitly without the real cost of the resources. That is not a mistake in the specification. It is how we price our work. Document B section 7.1 then places a second, conventional margin alongside it. Both must exist, and the two must never appear under the same label. A developer who quietly "corrects" this has broken the deliverable. - THREE KINDS OF PROGRESS, NEVER MERGED. Physical progress, financial progress and invoicing progress are three different numbers (RF-SAL-02). Most systems collapse them into a single percentage. This one may not. - AN OVERRUN DOES NOT CHANGE THE PLAN. When effort passes a threshold, the system records it, raises the alert, opens a control event - and leaves the baseline untouched (section 9.1 and AC-02). Baselines move only through an authorised change request. - THE INVOICING BLOCK IS DELIBERATELY SOFT. Exceeding the effort cap must warn and block, but never irreversibly: an override has to be possible, and has to demand a role, a written reason and a log entry (section 9.1). A hard block fails acceptance. A silent bypass fails harder. - RATES ARE VERSIONED BY VALIDITY DATE. Every historical calculation must use the rate that was valid on the date of the record, not today's rate (section 9.1). Get this wrong and every past margin figure silently rewrites itself each time the price list is updated. - EXTERNAL COLLABORATORS ARE ISOLATED AT RECORD LEVEL. RF-TIM-10 restricts an external to their own assignments only. That has to hold in the data layer, not by filtering a screen - a filtered screen is bypassed the moment anyone reaches the data another way. There are dozens more like these across the two documents. That is the job: reading carefully, asking when something is genuinely ambiguous, and implementing what was specified rather than what is customary. ------------------------------------------------------------ TECHNOLOGY The platform is fixed and is not open to substitution proposals. - Dataverse - data model, security roles, business rules, field-level security - Power Apps - model-driven for the operational core; canvas where the mobile experience requires it - Power Automate - workflows, approvals, notifications, scheduled jobs - Power BI - the five dashboards in section 7.2 - Copilot Studio - the agent in section 10 - Power Pages - only if the external-portal decision goes that way. It is one of the six open decisions in section 18.2; do not assume it - Microsoft Entra ID, SharePoint, Outlook/Exchange, Teams - identity, documents, calendar and mail, notification surfaces - ALM - managed solutions, separate development and test environments, pipelines, documented naming conventions Custom C# plug-ins only where configuration genuinely cannot do the job. "Configuration before customisation" is our own first principle (Document B, section 1.2), and I will hold you to it. ENVIRONMENT. You work in your own Power Apps Developer Plan environment (free, includes Dataverse) or your own trial tenant. You will not have access to our production tenant. Everything is built and demonstrated on synthetic data of realistic volume and shape. ------------------------------------------------------------ EXPLICITLY OUT OF SCOPE - PLEASE DO NOT QUOTE FOR THESE - Running the data migration. Our live production data will not be shared with you. The import interfaces, the field mapping, the deduplication rules of RF-ANA-06, the validation and the error reporting ARE in scope, demonstrated on synthetic data. Executing the migration is not. - Statutory fiscal behaviour - electronic invoicing format, withholding tax calculation, statutory accounting. Treated as already configured. You build the interface, not the fiscal logic. - Deployment into our production tenant. - End-user training. - Licence procurement and capacity sizing. - Direct contact with our staff or our customers. All communication runs through me. ------------------------------------------------------------ TIMELINE AND MILESTONES Four months maximum from kickoff. Fixed price, escrow-funded per milestone, released on acceptance. 1. Foundations: environments, ALM, Dataverse model, security roles, master data (6.1) - 3 weeks - $850 2. Engagements, planning, capacity, time reporting, approval and period lock (6.3, 6.4) - 4 weeks - $1,250 3. Progress statements, alerts, change control, revenue cycle and billing plan (6.5, 6.6) - 4 weeks - $1,250 4. Supplier cycle, expenses and travel, payment schedule (6.7, 6.8) - 3 weeks - $1,250 5. Financial control, Power BI dashboards, Copilot agent, end-to-end testing (7, 10, 16.2) - 3 weeks - $1,250 ACCEPTANCE is measured against the requirement IDs and the eight end-to-end scenarios in section 16.2 of Document B. A milestone is accepted when its requirements are demonstrated working on a screen share, on synthetic data, with no critical or high defects open. Not before, and not on the basis of a written status report. ------------------------------------------------------------ HOW TO APPLY Answer the five screening questions. Then, in your cover letter and in roughly 300 words or fewer: 1. Name the single requirement across the two documents you consider the riskiest, and say why. 2. Tell me which of the six open decisions in section 18.2 of Document B you would need closed before starting, and what you would assume in the meantime. 3. Confirm the timeline and the budget, or tell me plainly what you would change and why. ------------------------------------------------------------ WHAT GETS A PROPOSAL DECLINED WITHOUT A REPLY - A cover letter that describes my project back to me in general terms. I already know what my project is. - Anything that opens with "as an experienced Power Platform developer" and continues into a list of your skills. - A proposal that could have been written without opening the attachments. It is always obvious. - Answers to the screening questions that are fluent, confident, and wrong about what the documents actually say. - Questions to me whose answers are in the documents. - A price that is not the posted budget, quoted before you have read anything. I would rather receive four proposals from people who spent an hour with these documents than forty from people who spent four minutes with a language model. If you use AI to help you write, that is fine - so do I. But you must have read the documents yourself, because the screening questions cannot be answered from this job post alone.