Service

Development agency website development

For founders and directors of software and web agencies who need a website and client platform built around how they take enquiries, send proposals, run projects and support what they have delivered, rather than a brochure site plus five disconnected tools.

The problem

What goes wrong today

Where it usually starts

A development agency usually sells well and administers badly.

  • The website lists services in a few paragraphs; a prospect fills in a contact form with a sentence, and the first three emails are spent finding out what they actually need, what they use today and what they can spend.
  • Proposals are written in a document tool, sent as attachments and revised by email, so the version the client accepted and the version the team is building from can differ.
  • Acceptance is a reply saying "looks good", which later turns out to have come from someone without the authority to accept.

Where it gets harder

Once a project starts the client asks for updates by email and gets them when a project manager remembers.

  • Maintained clients report problems to whichever developer they know, by whatever channel they prefer, so the agency cannot tell how many open issues it has or how long they have waited.
  • Maintenance plans are agreed verbally and invoiced irregularly.
  • Case studies on the website are two years old because publishing one needs a client permission nobody has asked for.
  • The agency builds good systems for other people and runs its own business on inboxes.

Scope of the service

What the build covers

A custom build for a development agency covers the path from first visit to long-term support. The public side is a service and sector catalogue with distinct pages for each offering, structured case studies with brief, approach and outcome and a client permission record on each, insights publishing, and a partner programme page for referrers and white-label partners. The needs-capture wizard replaces the contact form: a branching set of questions about the business, the problem, current systems, constraints and budget band, saved as a draft and submitted as a structured enquiry the agency can triage.

The private side is the client platform. Proposals are composed in the system, sent as versioned documents, and accepted through a recorded action by a verified person, with the accepted version frozen. Each won project opens a portal where the client sees the stage the project is at, milestones, documents and decisions awaiting them. Maintained clients raise support tickets with a priority and a conversation thread, and the agency sees its whole support load in one queue. Maintenance plans are recorded as recurring arrangements with what they cover, and their renewal dates feed the billing tools the agency already uses.

Deliberately out of scope

  • Source control, deployment pipelines and issue tracking for developers, which stay in engineering tools
  • Accounting
  • Time recording, unless the agency wants timesheets as a named add-on

When the scope grows

Scoping scenario

A fifteen-person agency selling through three white-label partners wants partner-branded proposals, a portal where the partner sees its clients and the client sees only its own project, support tickets routed by plan level, and a wizard that varies by sector. That is a different build from a four-person studio with direct clients only, and the scope document names which parts apply.

Deliverables

What you receive

  • Discovery notes from following one recent engagement from enquiry to maintenance in your current tools
  • A written scope document naming each module from wizard to maintenance plan and what is left out
  • Designs of the service pages, the wizard, the proposal view and the project portal on phone and desktop
  • The build, including proposals, portal and ticketing where in scope, deployed to your hosting or ours
  • Import of existing case studies, clients and open maintenance arrangements with a redirect map for current URLs
  • Training for directors, project managers and developers who will answer tickets, with a short written guide for clients
  • Handover material and full ownership of the source code and your records

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the current site, proposal templates, the support inbox and the list of maintained clients and what each plan covers.

    Project stage: Onboarding
  2. Planning

    Discovery with a director and a project manager; the service catalogue, wizard questions, proposal rules, project stages and plan levels go into the scope document.

    Project stage: Planning
  3. Design

    The wizard, proposal and portal are designed for the client side first, since those are the screens that decide whether clients use the platform.

    Project stage: Design
  4. Development

    Built in layers: catalogue and case studies, then wizard and enquiries, then proposals and acceptance, then portal, tickets and plans.

    Project stage: Development
  5. Client review

    One real enquiry, one proposal and one maintained client are run through the platform in parallel with your current tools, and the team reports what does not fit.

    Project stage: Client review
  6. Revisions

    Changes from the review are made and re-checked against the scope document.

    Project stage: Revisions
  7. Ready for launch

    Clients and plans imported, acceptance flow tested with a test client, redirects checked, launch checklist signed off.

    Project stage: Ready for launch
  8. Delivered

    New enquiries arrive through the wizard and maintained clients are invited to the portal; hosting and maintenance continue under their own agreement if taken.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Accounting and invoicing software for proposals won and plan renewals
  • Payment providers for deposits and plan payments
  • E-signature services where a signed proposal is wanted
  • Email and messaging providers for ticket notifications and project updates
  • Calendar links for discovery calls after a wizard submission
  • Engineering issue trackers, so a ticket can reference an internal issue
  • Analytics and consent management platforms

How we would approach it

Worked example

Concept demo

A fifteen-person agency selling through partners

The situation

An agency delivers most of its work through three marketing partners who resell development under their own names.

Why it is a custom build

The custom route is needed because the agency, the partner and the end client each need a different scope of visibility over the same records.

The scope we would propose

  • A partner role that sees the enquiries, proposals and projects for its own clients and nothing else, proposals that carry the partner brand where the arrangement requires it
  • A project portal where the end client sees only its own project and the partner sees all of theirs, support tickets whose routing and priority follow the plan level the client is on
  • A wizard whose questions vary by sector so a retail enquiry and a membership organisation are asked different things

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of services and sectors in the catalogue and how distinct their pages are
  • Wizard complexity: branches, sectors and how enquiries are triaged
  • Proposal composition, versioning and whether e-signature is connected
  • Project portal depth, from stage and milestones to documents and decisions
  • Support ticketing volume and routing by plan level
  • Maintenance plans and the billing tools they feed
  • Partner or white-label visibility rules
  • Existing clients, cases and plans to import
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

When is the package the better choice than a custom build?

An agency selling directly to its own clients, with one wizard, one proposal format and one support queue, is usually served by the development agency package through configuration. Partner or white-label visibility, proposals under another brand or routing by plan level point to the custom route, and we say which during discovery.

How is a proposal accepted?

The client opens the current version in the platform and records acceptance as a signed-in, verified person. The accepted version is frozen with its terms, and later changes become a new version. Where a signature document is required, an e-signature service is connected.

Will our developers have to live in another tool?

Developers see the support queue and the project portal when they are answering a client; their day-to-day work stays in your engineering tools. A ticket can reference an internal issue so the two sides stay linked without duplication.

Can the wizard be long without putting prospects off?

The wizard branches, so a prospect answers only the questions that apply to them, and the draft is saved so they can return. Discovery decides which questions earn their place; the aim is a structured enquiry the agency can triage, not a form for its own sake.

Who owns the platform afterwards?

You do. The source code, enquiries, proposals, project records and tickets are handed over at delivery and can be exported at any time. Hosting and maintenance are optional and separately agreed.

Get a project quote for development agency software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote