BeeTcore Development Methodology SOP

Summary

BeeTcore Digital Solutions delivers every client project through a six-phase methodology built on Agile Scrum, whether the project is a content management platform, a custom web application, a headless build, a mobile app, a commerce platform, or a learning platform.

Work is planned and tracked in a shared project workspace, managed in version control, built and tested in separate environments, and released to production only after the client completes User Acceptance Testing (UAT) and gives written sign-off. Security is built in from the first phase, aligned to the OWASP Top 10, the principles of ISO 27001, and the Nigeria Data Protection Act 2023. The principles in this document are fixed. The specific tools and controls for each engagement are confirmed in its project agreement.

1. Purpose and scope

This Standard Operating Procedure sets out how BeeTcore plans, designs, builds, tests, deploys, and hands over client work. It shows what happens at each stage, who is responsible, and what must be true before work moves forward.

It applies to:

• Content management platforms, including WordPress, WooCommerce, Webflow, and Shopify
• Custom web applications and APIs
• Headless and decoupled architectures
• Mobile applications
• Commerce and learning management platforms
• Redesigns, migrations, and major feature work on existing platforms

It covers work delivered by BeeTcore team members and approved delivery partners.

2. How this standard applies

Every engagement follows the same phases, gates, quality standards, and security principles. The tools and controls that deliver them depend on the technology stack.

Content management platforms use platform-native controls: staging environments, revision history, pre-change backups, and platform security layers. Custom code written for them, such as themes, plugins, and extensions, is managed in version control.

Custom applications use a full engineering pipeline: version control with a defined branching strategy, peer code review, automated testing, continuous integration and deployment, and code-level security scanning.

The project agreement signed before work begins confirms the stack, environments, tools, and controls that apply to that engagement. Where this document and the project agreement differ, the project agreement governs.

3. Roles and responsibilities

Every engagement has named owners. On smaller projects, one person may hold more than one role, and each responsibility still applies. Specialist roles are assigned where the project requires them.

Project Manager
Owns the timeline, scope, sprint priorities, and client communication. Issues the weekly status update and manages approvals.
Accountable for delivery on schedule and within agreed scope.

Senior Delivery Lead
The escalation point on every engagement. Reviews scope, resourcing, and risk at key milestones.
Accountable for resolving escalated issues.

Business Analyst
Gathers and documents requirements, maps user journeys, and confirms that the build matches client needs.
Accountable for clear requirements, signed off by the client.

Design Lead
Owns information architecture, user flows, the design system, and visual design. Ensures accessibility and responsive behaviour are designed in from the start.
Accountable for approved designs that are on-brand and buildable.

Technical Lead
Owns system architecture, technology selection, coding standards, and code review.
Accountable for a scalable, secure, maintainable system.

Developers (front end and back end)
Build features, implement integrations, write tests, and resolve defects.
Accountable for working, reviewed code that meets the Definition of Done.

DevOps Engineer (custom and infrastructure-heavy projects)
Owns environments, CI/CD pipelines, deployment, and infrastructure configuration.
Accountable for reliable, repeatable deployments.

Quality Assurance
Runs manual and automated testing, and supports the client through UAT.
Accountable for complete test coverage and defect-free handover to UAT.

Security Specialist (where required)
Reviews architecture, code, and configuration against security standards.
Accountable for releases with no known critical vulnerabilities.

Content and Editorial
Writes or edits copy where it is in scope, proofreads all content, and completes on-page SEO fields.
Accountable for accurate, consistent content.

Client
Names a single point of contact with authority to approve. Supplies content, brand assets, and third-party access on the agreed dates. Reviews builds and completes UAT.
Accountable for timely feedback and sign-off. Delays on client inputs move the timeline by the same amount.

4. Planning and pre-development

No build starts without an agreed scope. Before development, BeeTcore completes the following.

Requirements extraction. Every requirement in the client’s brief is extracted line by line and confirmed back in the proposal, in the client’s own words where possible.

Discovery. Stakeholder conversations, a review of existing systems and content, and a technical audit of the current platform where one exists.

Dependency mapping. External dependencies are named explicitly. These include hosting and domain access, third-party accounts, payment gateway merchant accounts, APIs, and content delivery dates.

Scope definition. Features are documented in three groups: end-user features, administrator features, and platform-wide features. Anything not listed is out of scope.

Work breakdown and estimation. Scope is broken into tasks with owners and dependencies. Tasks are prioritised using the MoSCoW method (must, should, could, won’t) and estimated. The timeline is stated as a range, together with its assumptions.

Technical architecture review. Architecture, data model, integrations, and security controls are reviewed before build.

Project agreement. The agreement confirms scope, stack, controls, and responsibilities. Work begins after signature and written scope approval.

Project setup. Scope, milestones, and tasks are held in a shared project workspace. BeeTcore’s standard tools are used by default. Where a client has an established system for project management, documentation, or code hosting, BeeTcore works within it, and the tools for each engagement are agreed before kickoff. For projects with custom code, a private repository is set up with branch protection, coding standards, and a defined folder structure.

Onboarding. Access, brand assets, content, key accounts, and a single point of contact are collected at kickoff through a standard onboarding checklist.

5. Delivery lifecycle

Delivery runs through six phases. Each phase has a gate: it closes only when its deliverable is approved.

Phase 1. Discovery
Requirements gathering, stakeholder interviews, technical audit, dependency mapping.
Deliverable: documented scope and technical requirements.
Gate: client confirms scope.

Phase 2. Strategy and architecture
Information architecture, user flows, system architecture, technology selection, integration planning.
Deliverable: approved architecture and sitemap.
Gate: written approval.

Phase 3. Design
Wireframes, visual design, design system, responsive treatment for mobile, tablet, and desktop.
Deliverable: approved design files.
Gate: written design approval within the agreed revision rounds.

Phase 4. Development
Build in sprints against approved designs, integrations, content population, technical SEO, automated tests.
Deliverable: working build in the staging environment.
Gate: internal QA passed.

Phase 5. Testing and quality assurance
Full testing as set out in Section 8, followed by client UAT.
Deliverable: signed-off staging build.
Gate: written UAT sign-off.

Phase 6. Launch and handover
Production deployment, DNS and SSL configuration, post-launch monitoring, credential and repository handover, documentation and training.
Deliverable: live platform and handover pack.
Gate: handover accepted.

6. Agile workflow and communication

BeeTcore runs Agile Scrum, adapted for client delivery.

Sprints. Features and work are broken into sprint tasks using a prioritisation framework, then delivered in planned iterations. Each iteration ends with a review of completed work.

Standups. The delivery team holds regular internal standups to track progress and clear blockers.

Retrospectives. Each sprint closes with a short retrospective on what to improve.

Weekly status update. Every client receives a written update each week covering progress, next steps, open decisions, and risks.

Milestone reviews. Staging links are shared for review at each milestone.

Traceable feedback. Feedback is given as annotations directly on the staging build, in writing, or as short recorded walkthroughs. Live calls are used where they are faster, not by default.

Single source of truth. One agreed project workspace holds the scope, tasks, decisions, and approvals. Notion is the default. Written comments in the workspace and on shared documents form the record of the engagement.

7. Version control and branching

All custom code is managed in private Git repositories. No code reaches production outside version control.

Branching strategy

• Feature branches. Each feature or fix is built on its own branch.
• Development branch. Completed features merge here after peer review.
• Staging branch. Code is deployed to the staging environment for testing and UAT.
• Main branch. Holds production code only. It is protected, and changes arrive only through approved merges.
• Hotfix branches. Urgent production fixes are branched from main, reviewed, and merged back into every active branch.

Controls

• Every merge goes through a pull request with peer code review.
• Access to repositories is role-based. Only authorised team members can approve and merge.
• Releases are tagged, so any version can be identified and restored.
• Credentials, keys, and environment secrets are never committed to a repository.

Content management platforms

Custom themes, plugins, and extensions are held in version control. Content and page layouts are protected by platform revision history and backups taken before every change.

8. Quality assurance and testing

Testing runs throughout the build, then in full before UAT. A client never tests a build that BeeTcore has not tested first.

Automated testing (custom code)

• Unit testing. Core functions are tested in isolation.
• Integration testing. Modules, APIs, and services are tested together.
• End-to-end testing. Key user journeys are tested automatically in a browser.
• Pipeline checks. Tests and code quality checks run automatically on every merge. A failing check blocks the merge.

Manual and platform testing (every project)

• Functional testing. Every feature, form, user journey, and user role is tested against the agreed scope.
• Regression testing. Existing features are retested after changes.
• Cross-browser testing. Current versions of Chrome, Safari, Firefox, and Edge.
• Responsive testing. Mobile, tablet, and desktop, on real devices and emulation.
• Integration testing. Forms, CRMs, email delivery, analytics, and third-party services, end to end. Payments are tested in the gateway’s test mode before live keys are applied.
• Performance testing. Page speed, Core Web Vitals, and load behaviour, with optimisation before launch.
• Accessibility checks. Colour contrast, keyboard navigation, visible focus states, alternative text, and semantic structure, informed by WCAG 2.2 AA.
• SEO and GEO checks. Page titles, meta descriptions, heading structure, schema markup, XML sitemap, robots rules, canonical tags, and 301 redirects. Content is structured so AI search engines can read and cite it.
• Content proofing. All copy is proofread before client review.
• Security review. Each build is checked against the OWASP Top 10 before release, as set out in Section 9.

Defect tracking. Defects are logged, prioritised, fixed, and retested before sign-off.

User Acceptance Testing (UAT)

• The client tests the staging build against the agreed scope and gives feedback in writing.
• Revisions follow the number of rounds stated in the proposal.
• UAT closes with written sign-off. No build goes to production without it.

9. Security and compliance in development

Security is part of the build, not a stage after it. Every build addresses the OWASP Top 10 and follows the principles of ISO 27001 and privacy by design, in line with the GDPR, the Nigeria Data Protection Act 2023, and other applicable laws.

The full set of development controls, including the OWASP Top 10 checklist, security testing, and secure deployment, is set out in the Secure Web Development Framework. Platform protection, access control, and encryption are set out in the Cloud Security Framework.

Card payments are processed by the payment gateway, and card data is never stored on the platform. The legal wording of privacy notices is supplied by the client.

10. Environments, deployment, and rollback

Environments

• Local. Developers work in consistent, containerised local environments where the stack supports it.
• Development. Integrated code is tested internally.
• Staging. Mirrors production. Used for QA and UAT, and hidden from search engines.
• Production. Changed only through the deployment process below.

Deployment

• Custom applications deploy through automated CI/CD pipelines. A release reaches production only after tests pass and approval is given.
• Database changes are scripted and versioned alongside the code.
• Zero-downtime deployment is used where the architecture supports it.
• Content management platforms deploy through a controlled release process, with a backup taken immediately before.

Launch sequence

1. A final backup is taken of any existing platform.
2. The build is deployed at a low-traffic time agreed with the client.
3. DNS, SSL, and email records are configured and verified.
4. 301 redirects are applied from old URLs to protect search rankings.
5. Search Console, the XML sitemap, and analytics are connected.
6. Caching and CDN are enabled, and performance is measured again on production.
7. Forms, payments, integrations, and key user journeys are checked live.

Rollback

• Custom applications: redeploy the previous tagged release.
• All projects: restore the backup taken before deployment.
• If a defect cannot be fixed quickly, the platform returns to its previous state and the release is reassessed.
• Fixes after launch follow the Change Management Framework.

11. Performance and error monitoring

• Error tracking. Custom applications report errors in real time, with the detail needed to fix them quickly.
• Performance monitoring. Response times and bottlenecks are tracked, so slowdowns are found before users report them.
• Uptime and security monitoring. Every platform is monitored from launch day.
• Alerting. Alerts route to the responsible technical owner and follow the Incident Management Response Strategy.

12. Third-party integrations

• Client-owned accounts. Payment gateways, email services, CRMs, and analytics are held in the client’s name. Clients open their own merchant accounts.
• Secrets stay server-side. Keys are never exposed in front-end code, repositories, or plain-text messages.
• Least privilege. Keys carry only the permissions they need. Test keys are used during the build, and live keys are applied at launch.
• Usage limits. Vendor quotas and pricing tiers are reviewed against expected volume.
• Failure handling. Temporary failures are retried automatically, errors are logged, and users see a clear message.
• Handover. Keys created during the build are transferred or rotated at handover.

13. Definition of Done

A task or project is complete when:

• It meets the acceptance criteria in the agreed scope.
• Code has been peer reviewed and merged, with all automated tests passing (custom code).
• It works on mobile, tablet, and desktop, across supported browsers.
• It has passed internal QA and the security review.
• It has been deployed to staging and tested there.
• UAT has been completed and signed off in writing by the client.
• Documentation has been provided, where required.
• For a full project, the platform is live and verified on production, and handover is complete.

14. Documentation and handover

Every project closes with a handover pack. Depending on the build, it contains:

• An administrator and user guide
• A system architecture overview
• API references in OpenAPI (Swagger) format, for custom APIs
• Deployment instructions and an environment variable inventory
• A credential inventory, transferred securely
• Repository access, as set out in the project agreement
• A list of third-party dependencies with account owners
• Training material appropriate to the build

A handover session walks the client through the documentation.

Ownership of code, content, data, and accounts is set out in the project agreement and varies by engagement. Client content, data, and accounts belong to the client. BeeTcore retains ownership of its own tools, plugins, and components, which are licensed for use on the client’s platform.

15. Post-launch support

• Where applicable, a free post-launch support window covers defects found after launch.
• Ongoing updates, backups, security, and support continue under BeeTcare, BeeTcore’s managed maintenance service.

16. Document review

This document is reviewed annually and after any change to delivery practice. The latest update date is shown at the top of this page.

Frequently asked questions