Skip to content
Digital services for Birmingham

Give each part of the project a clear job.

Softglimmer helps Birmingham teams plan and build websites, ecommerce, business software, apps, automation and practical AI. We turn the intended customer and staff tasks into a design and development brief that people can review. Our studio is in Ranchi, India; discovery, implementation reviews and handover are organised remotely with your nominated owners.

Explore our work
Connect the brief without mixing its responsibilities.
  1. 01

    Identify the users

    Separate visitors, editors and operating colleagues.

  2. 02

    Describe the work

    Name the pages, functions and connections to include.

  3. 03

    Agree the review

    Give each deliverable a relevant acceptance task.

An example journey, shaped around your requirements.

One project conversation can cover several kinds of work.

You can approach us with a new website, an ecommerce requirement, an internal process or a combination of needs. The project can include discovery, content structure, identity and interface design, implementation, selected system connections and the operating handover. We identify which outputs belong together and which need a separate decision before estimating the work.

A public website, its publishing controls and a business application serve different people. A visitor may need to understand a service and make an enquiry. An editor needs to maintain approved information. A colleague managing requests may need records, permissions and a working queue. Describing those tasks gives a more useful starting point than asking for a single unspecified administration area.

The proposal names what Softglimmer will produce, what your team supplies and how both sides review it. You can start with a focused improvement or a larger build.

Keep the responsibilities understandable.

Make the distinction visible in both the proposal and the review.

01

Publishing is a real user task

Specify what an editor changes, who approves public facts and which shared page elements should remain consistent. Ask the intended editor to perform a representative update and confirm that the controls support the publishing task.

02

Operating work needs its own model

If staff manage customers, jobs or approvals, describe the records and decisions they need. Access rules and reporting require their own implementation scope; they do not follow automatically from website editing controls.

03

Connections need known owners

Identify the source of each shared value and the person who can provide authorised access. Agree what happens when information is unavailable or an action cannot complete, before promising a fully connected journey.

04

Presentation and behaviour both need review

Review the readability of the visual design and follow the agreed forms and application journeys through their intended tasks. Include relevant devices and alternative states in the acceptance review.

Specify outputs your team can recognise.

A tailored engagement can include these six deliverables, with their boundaries stated in the proposal.

01

Audience and task brief

A concise account of the customer, editor and operating tasks, the current tools and the first-release boundary. It records unresolved questions that affect the estimate.

02

Content and interface plan

The page structure or workflow, representative content, navigation and important screen states. Your approvers can review the proposed experience before implementation expands.

03

Agreed design assets

The agreed visual system, layouts or brand files, with formats and intended applications identified. List the editable files included in the handover.

04

Implemented release scope

The selected pages, store functions, application features or connections. Data movement, account setup and content entry are included only where the agreement assigns them.

05

Review and release record

Evidence from the agreed journeys, recorded feedback and remaining dependencies. Business-content approval and technical acceptance have identifiable owners.

06

Practical handover

An editing or operating walkthrough, access responsibilities and the agreed maintenance route. Future changes and recurring provider costs remain visible commercial decisions.

Bring the people who can explain the task.

Share the current website or tools, approved service information, available brand assets and one representative task. Bring the intended editor or operator into the discussion with the project owner. Sanitised samples can help explain the work. Identify material that is not yet available so the plan can record what is needed and who will provide it.

Where several departments contribute, nominate a person who consolidates their decisions. Record content, design and implementation decisions against the same approved brief.

Move from a shared brief to a usable release.

Review points follow the agreed project scope.

  1. 01

    01 · Discover and scope

    Discuss the intended users, existing arrangements and available inputs. Compare service options and prepare the written scope, responsibilities and estimate.

  2. 02

    02 · Review a representative part

    Use real approved content or a suitable sample to assess the proposed structure and interface. Resolve the important decisions before repeating the pattern across the build.

  3. 03

    03 · Implement and check

    Develop the agreed scope and review it through the named user journeys. Log questions against the relevant version so approvals remain understandable.

  4. 04

    04 · Release and explain

    Complete agreed release checks, demonstrate routine operation and provide the handover material. State any continuing support and later phase separately.

Plan remote decisions with the actual calendar.

Our Ranchi team can arrange remote reviews with your Birmingham contacts. Use dated invitations labelled Europe/London and Asia/Kolkata, confirm each participant’s local date and time, and recheck feedback deadlines when the meeting date changes.

Name the approvers, consolidate feedback and record decisions against the reviewed material. Agree review availability and support responsibilities in the project plan.

Questions before you start the project.

Can we start with a website and add software later?

Yes. We can define a complete public website scope and identify later operating requirements separately. The first release should explain its actual enquiry or purchase journey and identify any connections planned for a later phase.

Do you provide every service in one package?

We select the useful combination after reviewing the need. The proposal names the outputs, inputs, assumptions and review stages, so an identity project, a website and a custom application are not treated as interchangeable deliverables.

What do you need before giving an estimate?

The main task, current site or tools, available content and the people who own decisions are a good start. Important access, integration and data questions may need a scoped discovery step before implementation can be estimated responsibly.

How do we assess your work and delivery arrangement?

Review the documented website projects and discuss your requirements. The proposal explains remote delivery from Ranchi, the review process and the intended handover for your own project.