Full-Stack Developer for Internal Tender Management System (Web App, German-language UI)

WHO WE ARE AND WHY WE ARE HIRING LiL Service GmbH provides security and cleaning services in Germany. We bid continuously on public tenders from municipalities, federal states and national authorities. Today that work runs on Excel sheets, email inboxes and folders on a network drive. It holds up until something slips, and something slips regularly: a bidder-question deadline gets missed, a request for missing documents lands in the wrong inbox, and a year after losing a contract nobody remembers who we were up against or what went wrong. We want to replace that. The goal is a system where the entire tender operation happens, and from which we can tell, several years out, how our win rate, our pricing, our client relationships and our competitive position have actually developed. A full functional brief exists, 38 chapters. We share it after a first conversation. --- THREE THINGS THAT ARE NOT NEGOTIABLE Please only apply if you can meet all three. 1. A real web application. Every core function runs in the browser with no local installation. A stripped-down web view sitting next to a desktop version is not acceptable. Current versions of Chrome, Edge, Safari and Firefox, responsive across desktop, laptop, tablet and phone. Complex calculations get edited on desktop; tasks, approvals and deadline monitoring must also work on a phone. 2. The interface is German only. Navigation, buttons, statuses, error messages, notifications, forms, filters, dashboards, emails and exports are all in German. Our users are operational staff in the tender team, not developers. If you do not speak German, we need a clean i18n structure that we can populate ourselves, and you plan that review loop into your schedule. 3. Permissions enforced on the server. Roles control what can be retrieved, not just what is displayed. A hidden menu item without a server-side check counts as a bug here, not a feature. This matters most for prices, margins, competitor data and employee statistics. --- FUNCTIONAL SCOPE Two separated business areas Security services and cleaning services operate separately, each with its own dashboard, pipeline, tasks, templates, calculations, statistics and market analysis. Authorised managers compare both areas through a management overview without the teams' day-to-day work getting mixed together. Users, roles and individual rights Nine example roles, from super administrator through department head, tender team lead, calculation, concept writing, documentation and quality control down to regular staff. On top of that, individually assignable rights such as see prices, see margins, see competitor data, execute final submission, view employee statistics. Tender record and master data Every tender gets a permanent internal ID in the form LIL-S-2026-0084 or LIL-R-2026-0041, referenced system-wide across tasks, documents, communication, calculation, timeline, result and archive. Roughly 25 master data fields: business area, title, procurement number, contracting authority, procurement office, contact person, contact details, location with city and federal state, service type, sector, procurement procedure, estimated contract volume, contract term, contract start and end, extension options, submission deadline including time of day, bidder-question deadline, site visit date, bid validity period, publication date, source, portal link, notes, tender documents. The source is captured as structured data rather than free text, so that win rate, volume and quality per source can be evaluated later. The sources we use include TED, service.bund.de, oeffentlichevergabe.de, Vergabe.NRW, DTVP and subreport ELViS, plus direct enquiries, existing clients and referrals. We also need structured CPV code and NUTS code fields, because filtering and reporting run on those. Tenders with historical value are never deleted, only archived or flagged invalid. Technical junk entries can be deleted by authorised administrators alone, with a logged reason. Workflow and bid decision Eight phases from intake through review, decision, processing, quality, submission and follow-up to closure, ending in won, lost, cancelled, not evaluated or excluded. Every status change is recorded with user, date and time. Bid / no-bid: the system produces an internal participation score from contract value, expected margin, distance, staffing requirement, wage and qualification requirements, reference position, competitive intensity, contractual penalties, strategic value and past win rate. A person with the right permission makes the call, not the system. Declines are recorded with a reason too, because we want to know what we are walking away from and why. Team, tasks and dependencies Each tender has one clearly named tender owner plus any number of team members in the roles calculation, concept, evidence documents, quality control and final approval. Tasks carry title, description, owner, participants, priority, start date, due date, checklist, attachments, comments, creator, reviewer and completion date. Status chain: open, in progress, waiting on another task, in review, correction required, done or overdue. Tasks depend on each other. Final submission unlocks only once the calculation is approved, concepts and evidence documents are complete, formal review is finished and management has signed off. The system has to enforce that chain rather than relying on everyone's self-discipline. Deadlines and escalation The submission deadline is visible at all times and runs as a countdown. Fourteen deadline types, from bidder questions, site visit, internal calculation, concept, document check, approval, quality check, upload and submission through to document requests, presentation, negotiation, bid validity and expected decision. Four escalation levels: notify the assignee when a task goes overdue, inform the team lead after 24 hours, add the administrator when a critical task sits under 48 hours before submission, and raise a management alert under 24 hours before submission with critical items still open. Plus a central tender calendar filterable by department, employee, tender, contracting authority and deadline type. Documents and versioning Eleven document categories, from tender documents, calculation, concepts, evidence documents, references, bidder questions, communication and site visit through to final bid documents, result and post-analysis. Version history on everything. Once submitted, the final version is archived immutably. Calculation and approvals Two genuinely different calculation models. Security services calculate from deployment hours, collective wage rate, supplements, social costs, holiday and sickness cover, site management, operations management, uniforms, vehicles, equipment, admin overhead, risk and margin. Cleaning services calculate from cleaning area, performance rate, labour hours, collective wage rate, supplements, machines, cleaning agents, consumables, site management, admin, risk and margin. Multiple calculation versions side by side, plus bid price, hourly rate or price per square metre, minimum margin, target margin, actual margin, break-even and risk surcharge. A calculation that falls below the defined margin triggers a management approval step. Six-step approval chain: calculation checked, concept checked, evidence documents checked, formal review complete, management approved, final submission released. Each approval stores person, date, time and an optional comment. References, certificates, concept library Reference database with client, service type, sector, location, period, contract volume, headcount, contact person, description, reference letters and supporting documents. Certificate management for insurance, ISO certificates, trade registration, security licence under section 34a of the German Trade Regulation Act, tax clearance certificates, collective-wage compliance declarations and pre-qualifications, each with validity, expiry date and automatic reminders. An expired certificate is a real disqualification ground in our market, which makes this module more important than it sounds. Versioned concept library with reusable text blocks for quality management, staffing concept, cover arrangements, escalation, complaints, sustainability, training, deployment organisation and the security and cleaning concepts themselves. Communication, site visits, submission, follow-up Documented separately per tender: bidder questions, answers, clarifications, amendments, emails, phone calls and internal comments. Site visit record with date, attendees, contact person, photos, notes, access routes, parking, areas, risks, technical particularities, staffing requirement, competitors spotted on site and open questions. Submission with date, time, responsible employee, portal, transmission route, final files, receipt confirmation and notes. Then follow-up tracking across receipt confirmation, document requests, presentation, negotiation, queries, bid validity and expected result. Document requests get their own description, owner, deadline, files, status and history. Worth stating plainly: the submission itself still happens inside the respective procurement portal. Our system documents it, it does not replace it. Result, win/loss, lessons learned Result with winner, our rank, winning price where known, our price, price gap, award date, known evaluation, reasoning, award decision and documents. Win/loss analysis by price, quality, concept, references, experience, staffing, formal error, exclusion, capacity, contract terms, competitor or strategic decision. Plus three mandatory lessons-learned questions that stay part of the tender file permanently. Competitors, market, clients, pipeline Competitor database with company name, region, service areas, known clients, won and lost procedures, known prices, strengths, weaknesses, market segments and internal notes. Any price entry needs a mandatory source field, for competition law reasons. Analyses on top of that: who we face most often, who beats us repeatedly, which regions and which clients a given competitor is strong with, which service types are most heavily contested. Market analysis by federal state, city, region, sector, service type, client, contract size, contract duration, competitor, price level, source and procurement procedure. Client history with known procedures, our participations, wins and losses, win rate, past winners, typical competitors, contacts, contract terms and price development. From known contract end dates the system generates follow-up reminders at 12, 9 and 6 months out, explicitly including procedures we lost. Pipeline and forecast with open tenders, bid volume, weighted pipeline, internal win probability, possible contract start, expected annual revenue and margin. Resource check with staffing requirement, qualifications, region, start date, available capacity, recruitment need and operational risk. People, teams, cover Employee profile with tenders handled and in progress, completed, open and overdue tasks, on-time completions, correction loops, average handling time and sector experience. What gets recorded is actual contribution across calculation, concept, references, documentation, quality control, communication, final review and coordination, not merely who was assigned. Skills matrix, workload view before every new assignment, team performance per department, and a bottleneck analysis showing average duration per process step. One point we care about: the performance score weights on-time delivery, quality, task completion, reliability, documentation quality, correction loops and collaboration. Win rate may enter only as a secondary factor. Full rankings are visible to managers only. We are building a management tool, not a surveillance system, and the reporting exists to surface overload and bottlenecks. Holiday, sickness and other absences feed into the deadline logic. The system warns about deadlines falling inside an absence window and supports assigning cover with full history preserved. Activity log, audit trail, notifications Immutable timeline per tender covering creation, team assignment, tasks, corrections, approvals, submission and result. Audit log for critical changes with user, action, previous value, new value, date and time, specifically for submission deadline, price, document deletion, team assignment, status and result. Internal comments with mentions and attachments, clearly separated from official correspondence. Notification centre in the browser, optionally by email. Search, filters, dashboards Global search across tender ID, procurement number, client, procurement office, city, employee, competitor, winner, document, title and service type. Combinable filters across period, department, status, employee, region, federal state, volume, competitor, service type, sector, procedure, source and outcome. Three dashboards cut differently: employee, team lead and management. Plus a deadline radar sorted by urgency and an activity feed. Statistics, archive, reporting Win rate, participation rate, bid volume, won and lost volume, average contract value and margin, average handling time, formal exclusions, deadline reliability, how far ahead of deadline we submit, regional analysis, sector analysis, source analysis, loss reasons, and price and competitor development. One metric gets special treatment: formal exclusions. Target value zero. A bid thrown out on a technicality is work with no return whatsoever, and preventing exactly that is a large part of why this system exists. Closed tenders stay fully searchable. Automatic monthly, quarterly and annual reports, exportable as PDF and Excel for pipeline, win/loss, competitors, employee and department performance, deadlines and management reporting. Later expansion stages The architecture should keep two extensions open without building them now. First, import connectors. TED offers an open search API, oeffentlichevergabe.de an open data interface, service.bund.de custom RSS feeds. The plan is an intake inbox that receives new notices filtered by CPV code and region, deduplicated by procurement number, which an employee triages as relevant or not with a single click. Second, AI assistance for extracting deadlines, contract terms, eligibility criteria, required certificates, award criteria and contractual penalties from uploaded documents. Every AI output is labelled as a suggestion and confirmed by a person. The system does not automate decisions. --- TECHNICAL REQUIREMENTS Pick the stack that fits your experience. Functionally the architecture has to cover these layers: Responsive web frontend with German UI, role-based menus, tables, dashboards and uploads. Backend holding business logic, workflow, permissions, deadlines, notifications and exports. Relational database with cleanly separated entities for tenders, users, tasks, documents, calculations, clients, competitors, results and history. File storage with versioning and immutable final submission versions. Scheduler for deadline reminders, escalations, follow-up reminders and periodic reports. Reporting to PDF and Excel. Audit and logging layer. Further requirements: Statistically relevant data is stored structured, not as free text. Unknown values are stored explicitly as unknown rather than left blank. Encrypted transport over HTTPS, secure password storage, protection against the common web attacks, secure session handling, password rules and optional two-factor authentication. Regular database and file backups with a documented restore procedure. Separate staging and production environments. GDPR-compliant handling of employee, client and company data, hosted in the EU. Clean API and modular architecture for later extensions. On the interface: corporate design in white and very light greys, company red as the accent and action colour, dark grey for text and navigation. Green for success and wins, orange for warnings, red for critical, overdue and lost. Clear tables, modern cards, high information density without visual clutter, and one consistent design system for buttons, badges, status chips, tables, dialogs and form fields. The tender detail page shows status, owner, team, progress, submission deadline, risk, contract value and participation score immediately in the header, with tabs below for overview, tasks, calculation, documents, team, communication, bidder questions, site visit, approvals, competitors, submission, result, post-analysis and activity log. --- ACCEPTANCE CRITERIA FOR THE FIRST PRODUCTION VERSION Login with roles and separated business areas. Create and edit tenders, assign teams, run the full status workflow. Tasks with owners, deadlines, priorities, review and correction loop. Countdowns, reminders and the defined escalation levels. Document file with versioning and a final submission version. Calculation as a structured, versioned area with access control. Documented approval steps. Logged submission with follow-up and document requests. Result capture including winner, price, win and loss reason, and lessons learned. Competitor and client history that builds over time. Employee and team lead dashboards plus a management overview. Global search, combinable filters, archive, PDF and Excel export. Audit log for critical changes. Responsive use on desktop, tablet and phone. All production system text in German. --- CONTRACT FORM AND DELIVERY STAGES One point that decides how the price should be read: what we are contracting is the complete functional scope described in this posting, as one fixed-price project, Phase 1 through Phase 5 inclusive. The stated price covers the finished, acceptance-ready solution. It is not the price of a single phase, not an entry price, and not a basis for renegotiating scope later. The five phases structure the order of delivery. They do not split the contract. Phase 1: data model, roles, business areas, tender workflow, tasks, deadlines. Phase 2: documents, calculation, approvals, submission, result, archive. Phase 3: dashboards, search, filters, reporting, people and team management. Phase 4: competitors, market intelligence, client history, forecast, follow-up reminders. Phase 5: optimisation, automation, optional AI features. Payment runs through milestones along these phases. We accept each milestone before the next one starts. The total price is fixed from the outset. The fixed price also covers locking down the data model, role matrix, state machine, deadline and escalation logic, and document versioning. That alignment happens before implementation and is not unpaid pre-work. Not included: hosting, domains and third-party licences, plus maintenance and further development after acceptance. We discuss those separately. --- WHAT YOU SHOULD BRING Several years building business web applications where roles, workflows and historical records actually matter. A framework you are genuinely fast in, rather than a stack you want to learn on this project. Real practice with relational data modelling, server-side authorisation, file versioning, background jobs, and PDF and Excel generation. Experience with GDPR requirements and EU hosting. Clean, documented, testable code another developer could pick up. Helpful but not required: German language skills, experience with public procurement or facility management, experience integrating external tender APIs. One note on expectations: we want a company system that stays maintainable for years, not a fast prototype. Plan for a project that stays with you for several months, and price the full scope rather than an entry point. We release the complete 38-chapter functional brief before contract signature, so that your fixed price rests on the actual level of detail rather than on an estimate.