100 practical answers about website planning, redesign, packages, SEO audits, WordPress, WooCommerce, Merchant Center, hosting migration, security, maintenance, APIs, integrations, automation, databases, portals, apps and local project process for Lowveld businesses.
Last reviewed:
Category
Getting started and website planning
Lowveld Web designs websites, online stores, SEO foundations, and practical software systems for businesses and organisations in Nelspruit/Mbombela and the wider Lowveld.
Lowveld Web helps local service businesses, tourism and hospitality brands, retailers, and growing organisations improve how people find them, understand their offer, and make contact. Services include website design, WordPress, ecommerce, SEO, maintenance, redesigns, custom software, databases, business web applications, mobile applications, client portals, and systems integration. Projects are scoped around the business goal rather than a generic template.
Yes. Lowveld Web creates practical websites for small businesses that need clear services, trust information, and simple routes to call, WhatsApp, or request a quote.
A small business does not necessarily need a large or complicated website. The right starting point may be a focused site with a strong home page, service pages, contact details, FAQs, and a clear call to action. The scope can grow later as the business adds services, content, ecommerce, booking, or internal systems.
Prepare your business details, services, target customers, town or service area, preferred pages, contact details, photos, and any reference websites you like.
A quote becomes more useful when Lowveld Web understands what you offer, who you serve, what the website should achieve, and which actions visitors should take. It also helps to share your existing logo or colours, available text and images, current website address, required integrations, and any timing or budget considerations. You do not need to have everything written perfectly before making contact.
The timeline depends on the number of pages, features, content readiness, feedback speed, and integrations required.
A focused brochure-style site usually has a different schedule from an ecommerce store, booking journey, or custom web application. Lowveld Web agrees the scope and then provides a realistic project schedule rather than promising one universal turnaround time. Having approved content, images, access details, and feedback available generally helps the project move more smoothly.
It needs enough pages to explain the offer, build trust, answer important questions, and make the next action obvious.
A typical service-business site may need a home page, about or trust page, service pages, FAQs, and contact page. A tourism brand may need accommodation or experience pages, location information, policies, and enquiry or booking routes. An ecommerce site needs categories, product pages, checkout, delivery, returns, and customer-support information. The correct page count follows the customer journey, not an arbitrary number.
Website cost depends on pages, content, design, features, integrations, ecommerce requirements, and support. Lowveld Web publishes indicative package starting points and can provide a project-specific quote.
A simple online presence has different requirements from an online store, booking system, or custom business application. Costs can include planning, design, development, copy and image preparation, payments, integrations, hosting, maintenance, and future improvements. Lowveld Web’s package page provides current indicative starting points, while custom software and larger systems are scoped after understanding the workflow.
Lowveld Web offers Bronze, Gold, and Diamond all-inclusive package options, with indicative starting points shown on the packages page.
The package structure is intended to make managed website services easier to compare. Bronze is positioned as a practical online presence, Gold supports selling online with a managed store and marketing essentials, and Diamond is aimed at premium growth, bookings, and strategy. The exact scope and inclusions should be confirmed in the current proposal because project needs differ.
Hosting, maintenance, updates, and support are included according to the selected package and agreed scope.
The package pages explain what is included in each current package. Hosting arrangements, ownership, support boundaries, update requests, and any custom third-party costs should be confirmed in the proposal before work begins. Custom applications and business software are quoted separately because their infrastructure and support requirements can differ from a standard marketing website.
Yes. A focused website can be planned so that it provides a useful first version and can later expand with more pages, ecommerce, bookings, or systems.
Starting with the most important customer journey can be sensible when the business is still collecting content or validating an offer. The initial structure should still use a clean domain, sensible page hierarchy, secure access, and an architecture that does not make future improvements unnecessarily difficult. Lowveld Web can discuss an appropriate package or a staged project approach.
Yes. Businesses can submit a brief with their brand direction, content, reference sites, and required pages so Lowveld Web can prepare a sample and quote.
The free website sample is designed to help a business see a possible direction before committing to an all-inclusive package. The brief should include the business identity, colours, preferred look and feel, reference websites, available content and photographs, pages needed, and important features such as WhatsApp, forms, shops, or booking tools.
Ask for discovery, design, content work, migration, redirects, integrations, testing, launch support, licences, and recurring services to be clear enough to compare.
Comparing proposals is difficult when one quote groups essential work into a single vague line. An itemised scope helps you see whether planning, content migration, SEO migration, quality assurance, launch support and third-party services are included or simply assumed. It also makes exclusions and client responsibilities easier to discuss before they become surprises. The sensible next step is to compare scope and ongoing commitments, not just the headline price.
The proposal should distinguish the managed package from variable third-party, content-production, transaction, or specialist-integration costs before work begins.
A monthly package can make planning easier, but it is fair to ask what remains dependent on your particular needs. Original photography, specialist copywriting, premium software licences, payment-provider fees and complex integrations may have different cost structures from the core website service. Exact inclusions should be confirmed in writing rather than inferred from a starting price. The sensible next step is to ask for a total-cost view that separates recurring services from variable and third-party charges.
Clear positioning, useful service information, trust signals, mobile usability, and a visible next step all contribute to a stronger enquiry path.
Visitors should quickly understand what the business does, who it helps, where it operates, and what to do next. Pages should answer common objections, show relevant proof where available, make phone and WhatsApp actions easy to find, and keep forms focused. Good design supports the decision; it does not replace clear information.
Many visitors use phones, so navigation, text, images, forms, calls, WhatsApp, and performance need to work well on a small screen.
Mobile-first design means the main visitor journey is planned for a phone rather than treating mobile as a reduced desktop version. Important actions should be easy to tap, pages should remain readable, images should be optimised, and forms should be short enough to complete comfortably. This is particularly important for tourism, local services, and visitors making quick decisions while travelling.
A service page should explain the service, the customer problem, the likely outcome, what is included, who it suits, common questions, and how to enquire.
A useful service page is more than a heading and a short paragraph. It should use plain language, describe the process or deliverables honestly, include relevant proof or examples, answer objections, and link to the next useful page. Service pages can support both visitors and search engines when the content is original, specific, and genuinely useful.
Lowveld Web can help structure content and clarify what information each page needs; business claims and facts should be approved by the client.
A website project often needs help turning rough notes into clear sections, service descriptions, FAQs, and calls to action. The business should provide or approve factual details such as services, qualifications, prices, operating areas, policies, and customer examples. Lowveld Web’s approach is to improve clarity without inventing claims about the business.
Yes. Phone, WhatsApp, email, and enquiry-form actions can be placed where they are useful, especially on mobile.
Contact actions should be visible without overwhelming the page. A website can include click-to-call links, WhatsApp links with a prefilled message, email links, maps, and enquiry forms. The exact implementation should be tested on real phones and connected to the correct business contact details.
A redirect map should pair each important old URL with its closest relevant new URL, state the permanent redirect to use, record who owns the change, and leave room for testing results.
It is understandable to worry that a better-looking website could lose hard-won traffic or enquiries. Before URLs change, we would identify the pages people and search engines use, map each retained page to the most relevant replacement, and use permanent server-side redirects where appropriate. The map should also record testing and post-launch monitoring, so there is a clear route to investigate anything that does not behave as expected. The sensible next step is to request the redirect map as a named redesign deliverable before launch planning begins.
Agree baseline and follow-up measurements for the important pages, then review loading, interaction and layout-shift signals alongside the real customer journey.
It makes sense to want evidence that a redesign improved more than appearance. Google’s Core Web Vitals provide a useful framework for loading, responsiveness and visual stability, but they should be read with the pages and devices that matter to your visitors in mind. A practical plan records the baseline, identifies the pages to test, and reviews results after launch rather than making a blanket promise. The sensible next step is to include performance measurement and reporting in the redesign scope.
An accessibility review can make the scope explicit by identifying relevant WCAG success criteria, the intended conformance target, and how manual and automated checks will be used.
Accessibility is easy to assume and difficult to confirm after the fact, so it is wise to ask what will actually be tested. WCAG provides internationally recognised guidance, but the appropriate review depends on the site, audience, content and any obligations that apply to the organisation. Automated tools can help find issues, while human checks remain important for journeys such as navigation, forms and readable content. The sensible next step is to agree the accessibility scope and review method before design approval.
Test every important contact route on real devices, confirm where each submission goes, check notifications, and retain a record of the result before and after launch.
When enquiries matter, a beautiful site is not enough if a visitor cannot reach the business. The launch checklist should cover forms, confirmation messages, email delivery, phone links, WhatsApp actions, maps and any booking or payment step that supports a lead. These checks should be repeated on a phone as well as desktop, because the customer journey is often different. The sensible next step is to identify the revenue-critical actions and make them formal launch sign-off tests.
No. Lowveld Web provides SEO foundations and ongoing improvements but does not guarantee a specific ranking position.
Search visibility depends on relevance, competition, location, prominence, website quality, content, links, reviews, and many other factors. A responsible SEO process improves crawlability, page structure, content clarity, internal links, local information, and measurement. It should focus on attracting relevant visitors and enquiries rather than making an unsupported ranking promise.
There is no universal timeframe. Results depend on the site, competition, location, technical condition, content, authority, and how consistently improvements are made.
Some technical or page-clarity improvements may be discovered relatively quickly, while competitive local searches can take longer. Google must crawl and process changes, and competitors are also improving. Progress should be assessed using impressions, clicks, relevant queries, rankings, calls, WhatsApp clicks, forms, and qualified enquiries rather than one number alone.
Local SEO helps search engines and customers understand what a business offers, where it serves, and why it may be relevant to a local search.
Local SEO can include an accurate Google Business Profile, consistent business information, useful service and location pages, relevant content, reviews, local proof, internal links, and technical foundations. Google explains local results mainly through relevance, distance, and prominence. Local SEO should reflect the real business and service area rather than repeating town names unnaturally.
A Google Business Profile is useful for eligible local businesses that want accurate information to appear in Google Search and Maps.
The profile should contain accurate business information, category details, service information, hours where applicable, photos, and a link to the correct website. Businesses should monitor reviews and respond professionally. A profile does not guarantee a particular position, but complete and accurate information helps Google and customers understand the business.
SEO foundations can include page titles, meta descriptions, heading structure, internal links, crawlability, sitemap and robots setup, schema where appropriate, and performance-minded implementation.
Foundations make it easier for search engines to understand and discover a site. They are not the same as ongoing SEO, content production, link development, or a ranking guarantee. The exact inclusions should be confirmed for the project and package, especially when third-party systems or custom applications are involved.
A practical audit should examine indexing, crawlability, important-page health, site structure, page experience, structured data, and the on-page issues that block useful improvement.
It is sensible to understand the underlying site before committing to ongoing work. A technical audit should show what is discoverable, what is not, which pages matter most, and where the business can make responsible improvements rather than promising a ranking outcome. The findings should be prioritised by impact and effort, with explanations that a non-specialist can follow. The sensible next step is to request an audit with a clear list of evidence, recommendations and ownership.
A live page may still have an indexing, crawlability, canonical, content, or technical issue, so it needs page-level investigation rather than guesswork.
This can be worrying when a service page represents work your business depends on. Google Search Console provides reports and URL inspection tools that can help investigate whether Google can access and index a specific page, but the cause can differ from one site to another. The useful response is to check the page, its links, directives and status systematically instead of making broad changes. The sensible next step is to inspect the exact URL and retain the evidence in the technical audit.
Use Search Console performance data to review queries and pages with visibility but comparatively weak clicks, then assess whether the page answers the searcher’s need clearly.
It is easy to publish more content without knowing whether existing pages are already close to helping the right people. Search Console can show query- and page-level impressions and clicks, which creates a more grounded starting point for improvement. Numbers should be interpreted in context, because intent, seasonality and search-result features can influence them. The sensible next step is to identify a small set of important pages and review the associated queries before rewriting anything.
Duplicate URLs can split signals and complicate reporting; canonical annotations tell search engines which version you prefer, though they are hints rather than guarantees.
Duplicate pages are not always obvious because they can arise from filters, protocol versions, parameters, staging copies or similar content. Google explains that canonicalisation helps it select a representative version, but a canonical tag should match the actual site structure and not be used as a quick fix for unrelated pages. The issue is best diagnosed from the URL patterns and business purpose involved. The sensible next step is to list duplicate patterns and decide which public version should be primary.
Use structured data only where the page visibly and accurately supports the relevant type, then validate the markup and monitor it after release.
Structured data can sound like a shortcut to enhanced search results, so it is worth setting realistic expectations. Google says it can help search engines understand a page and may make a page eligible for rich results, but eligibility is not a display guarantee. The markup must describe information visible to users and should be tested before launch. The sensible next step is to review the site’s genuine content types and choose a small, accurate implementation plan.
AI can assist a careful editorial process, but content should remain accurate, useful, reviewed by people who understand the business, and not be published merely to manipulate rankings.
It is reasonable to explore faster ways to prepare content, particularly when a team is busy. Google’s guidance focuses on helpful, reliable, people-first information rather than the mere use of a tool, so the real question is whether the page adds truthful, useful value for the reader. Business claims, expertise, local facts and material automation should be handled transparently where readers would expect it. The sensible next step is to define an approval process that keeps a knowledgeable human responsible for every published page.
A useful report can cover search queries, important pages, impressions, clicks, indexing concerns, technical changes, and agreed next actions alongside any rank tracking used.
Ranking snapshots alone rarely explain whether the website is becoming more useful to the right audience. Search Console offers information about how queries and pages perform in Google Search, while technical reports can highlight indexing and site-health work. The report should connect the evidence to the work completed and the next sensible priority, without pretending that every change has a simple one-to-one outcome. The sensible next step is to agree the decision questions the report must answer before an SEO engagement starts.
Google says local results are mainly influenced by relevance, distance and prominence, so a complete profile helps but does not create a guaranteed position.
This is a frustrating situation, especially when your details are accurate and your business serves the area well. Google explains that local visibility is based on a combination of relevance, distance and prominence, and it does not offer a way to buy or request a better local ranking. The productive approach is to check whether the profile and website give clear, consistent evidence of the services and locations that matter to customers. The sensible next step is to review local visibility alongside customer search behaviour instead of focusing on one map position alone.
WordPress can suit businesses that need a flexible content-managed website, provided it is structured, maintained, secured, and kept focused on the business goal.
WordPress is useful when a business wants to manage pages, articles, images, or products through a content management system. The right choice depends on required features, editing needs, integrations, performance, security, budget, and support. A WordPress site should not be treated as maintenance-free after launch.
WordPress can allow you to edit supported content, although access, training, page structure, and maintenance responsibilities should be agreed before handover.
Some businesses prefer to update their own blog posts, images, or basic page content, while others prefer managed updates. Editing access should be set up with appropriate permissions and a clear understanding of which changes are safe to make. Lowveld Web can discuss handover guidance and ongoing maintenance.
A WordPress migration can be planned, but the process needs a backup, access to the current site and domain, compatibility checks, testing, and a careful launch plan.
A migration may involve files, databases, email or DNS settings, forms, images, redirects, analytics, plugins, and hosting. The current site should be backed up before changes are made. A staging or test process can reduce disruption, and important URLs should be checked so that useful search visibility is not lost unnecessarily.
Yes. Website maintenance can include practical content updates, improvements, security attention, and agreed support tasks.
Websites often need new services, images, articles, prices, policies, forms, or technical updates after launch. A maintenance arrangement helps keep the site current and gives the business a clear route for requesting changes. The work included and response expectations should be confirmed in the relevant package or agreement.
Training or handover guidance can be discussed where the business will manage content or users after launch.
The appropriate level of training depends on the platform, the people who will use it, and the type of updates they need to make. It is useful to agree which content the client will manage, which changes should be requested, how access is protected, and where support is available. Training should be practical and based on the actual website.
Use a protected copy of the site to check design, content, mobile behaviour, forms, checkout where relevant, integrations, and launch settings without interrupting the live site.
A live website is often too important to use as a testing ground, especially when it receives enquiries or sales. A staging site gives the team space to review page layouts, approved content, menus, contact journeys, integrations and device behaviour before the public site changes. It should be clear who approves each test and how any issues are recorded and corrected. The sensible next step is to agree a staging checklist and sign-off point in the project plan.
A backup is only reassuring when a documented restore test confirms that both the site files and the separate database can be recovered in a safe environment.
It is reasonable to ask for proof of recovery rather than simply being told that backups exist. A WordPress restoration normally needs both the website files and the database, so the test should confirm that the expected pages, media, settings and key functions return together. Testing should take place away from the live site and record any missing credentials, files or steps. The sensible next step is to ask for a restore-test plan before a rebuild, major update or host move begins.
Review the theme, active plugins, custom code, update history, licences, speed, security, and the business function each element still serves.
A visual refresh can be attractive, but an older site may also carry compatibility, performance or maintenance issues that deserve a clearer look. An audit helps separate items worth retaining from unused plugins, brittle customisations and features that need a safer replacement. It also makes the scope more honest because the project can be based on what the site actually requires, not assumptions. The sensible next step is to request a written audit summary before choosing a refresh or rebuild.
Collect domain and hosting access, WordPress administration, backups, analytics, email, media, licences, source files, and access to any connected services.
Transitions can be stressful when key accounts or files sit with a previous supplier. A clear handover list reduces delay and helps the new team assess what can be reused, secured or replaced. Access should be transferred through agreed secure channels, and ownership should be clarified rather than relying on informal shared passwords. The sensible next step is to work through a handover checklist before the redesign schedule is finalised.
Yes. Lowveld Web builds ecommerce websites with product structure, mobile-friendly shopping, and checkout flows planned around real customers.
Ecommerce planning should cover products, categories, variations, stock, prices, payments, delivery or collection, returns, refunds, customer emails, security, and support. A store should be easy to browse and use on a phone. The best platform and integrations depend on the product range, business process, and required control.
No. A focused range can be a sensible starting point if the products, fulfilment, payments, delivery, and support process are ready.
Starting with a manageable product range can make it easier to test product information, checkout, stock handling, delivery, and customer support. The store structure should allow additional products and categories later without creating a confusing buying journey. Launch scope should follow the business’s ability to fulfil orders reliably.
Payment options depend on the chosen ecommerce platform, payment provider, business verification, country, product type, and technical requirements.
Payment integration should be discussed early because providers may require accounts, verification, settlement details, and specific checkout or webhook flows. The website should be tested with successful, failed, cancelled, and refunded payment scenarios. Lowveld Web can assess the required connection during planning rather than assuming every provider works the same way.
Many ecommerce platforms can manage products and orders, but the appropriate workflow depends on stock levels, suppliers, fulfilment, and existing business systems.
A simple store may need basic stock quantities and order notifications. A growing retailer may need multiple locations, supplier information, accounting, delivery, customer records, or an integration with another system. The correct approach should be mapped before development so that the store does not create duplicate or unreliable records.
It also needs categories, search or filters where useful, checkout, payment, delivery, returns, privacy information, contact support, and clear trust information.
Customers need to understand what they are buying, what it will cost, when it will arrive, what happens if there is a problem, and how to get assistance. These details are part of the customer experience and should not be left until after the visual design is complete.
Compare merchant eligibility, ZAR and international-customer support, transaction and plugin costs, security responsibilities, checkout experience, and recurring-payment compatibility.
Choosing a gateway can feel consequential because it affects how customers trust and complete payment. The right comparison is not only about the transaction fee; it should also consider the store currency, accepted payment methods, settlement process, support, plugin maintenance and whether subscriptions are needed. The provider’s current terms should be checked directly because capability and pricing can change. The sensible next step is to list the store’s payment requirements and compare providers against the same criteria.
WooCommerce’s Payfast documentation states that payments may be accepted from any country while the store currency must be ZAR; confirm the current provider terms for your own merchant account.
Selling beyond South Africa raises sensible questions about currency, settlement and the shopper’s payment experience. Payfast’s WooCommerce guidance describes support for payments from any country with the store currency set to ZAR, but business eligibility and current provider requirements should be verified before relying on that setup. It is also worth checking how refunds, customer communication and accounting will work in practice. The sensible next step is to confirm the intended markets and review the provider’s current onboarding terms.
It can be planned where the store, subscription extension, and selected payment gateway support automatic recurring payments for the required customer journey.
Recurring payments can simplify a genuine repeat-purchase or subscription offer, but they need to be designed carefully rather than added as an afterthought. WooCommerce distinguishes automatic from manual subscription payments, and gateway support can differ by provider and payment method. The customer-facing cancellation, renewal, notification and failed-payment journeys deserve equal attention. The sensible next step is to confirm the subscription model and test gateway compatibility before committing to the feature.
They serve related purposes: structured data helps Google understand product pages, while Merchant Center provides product data; using both can support stronger data consistency and eligibility.
This is a sensible question because product discovery on Google involves more than putting items on a website. Google explains that page-level structured data and Merchant Center product data can work together, but neither is a promise that a product will appear in a particular result or surface. The information shown to Google must accurately match what shoppers see. The sensible next step is to review the catalogue and decide whether the store needs one route or a coordinated implementation of both.
Give each product a useful, crawlable page and then evaluate the relevant structured-data and Merchant Center routes for the Google surfaces that fit the catalogue.
Retailers understandably want a store to be discoverable as well as able to take payment. Google documents different product-discovery surfaces and the data approaches that may make a product eligible, but visibility depends on accurate information, site access, policy compliance and Google’s own systems. The best starting point is a well-organised catalogue with clear product pages, pricing, availability and images. The sensible next step is to prioritise the product categories that matter most and assess their data readiness.
Core information such as price, availability and the product identity should be consistent between the landing page, checkout, structured data and Merchant Center submission.
Listing problems are frustrating because a small mismatch can affect whether a shopper sees reliable information. Google’s Merchant guidance expects product data to reflect the landing page and checkout, so price, availability and relevant product attributes need clear ownership and a dependable update process. This is especially important when stock or prices change often. The sensible next step is to map the source of truth for each product field and test a sample before publishing the full feed.
Use crawlable links from navigation to categories, subcategories and products, rather than expecting search engines to discover products only through an internal search box.
A catalogue can be easy for staff to manage yet still be hard for search engines to reach if its structure is unclear. Google recommends a logical route through menus and category pages to products, with normal links that can be crawled. This also helps customers browse when they are not sure of the exact product name. The sensible next step is to sketch the category hierarchy and check that every important product is reachable through links, not only internal search.
It may be suitable for product information, but Google distinguishes product snippets from merchant listings for directly purchasable offers, so the markup must reflect the real page experience.
Many businesses need an online catalogue before they are ready for full checkout, and that is a valid model. The important point is not to mark an enquiry-only offer as though it can be purchased directly on the page. Google’s product documentation differentiates these experiences, so visible content and any structured data need to be accurate and specific. The sensible next step is to decide whether each product is a catalogue enquiry, a quote request or a buy-now offer before implementing markup.
Represent real variations with consistent attributes and product relationships so customers and Google can distinguish choices such as size, colour, material or configuration.
Variations are a common source of confusion because one product may be sold in several genuinely different forms. Google recommends product-variant structured data, while Merchant Center expects relevant variant attributes to be accurate. The store should first decide what is a true purchasable variation and what is simply descriptive information. The sensible next step is to model a small group of representative products correctly, then apply the agreed pattern across the catalogue.
Supply accurate shipping cost, service, delivery area and, where applicable, handling and transit-time information that matches what customers can expect at checkout.
Shipping is often where a promising purchase becomes uncertain, so clear information helps both shoppers and product listings. Google’s product data guidance covers shipping cost, locations, service and delivery timing, and the store itself needs to communicate the same reality. Complex delivery rules should be designed around actual operations rather than guessed for the feed. The sensible next step is to document delivery zones, charges and lead times with the fulfilment team before configuring Merchant Center.
Offer a clear guest-checkout route, keep mobile fields focused, show costs and delivery information early, and test payment and error states on real phones.
It is understandable to want customer accounts for repeat business, but forcing registration can add friction at a sensitive moment. Checkout design should give shoppers a straightforward guest option where it fits the business model, then invite account creation after the purchase if it is useful. Longer or more complicated forms should be challenged, particularly on a phone. The sensible next step is to review the current checkout journey with real customer tasks and prioritise the clearest friction points.
A domain is the web address people use to find a site; hosting is the server space and infrastructure where the website files and application run.
A domain such as yourbusiness.co.za points visitors toward the website. Hosting provides the environment that serves the website to them. Email, DNS, SSL, backups, database services, and application resources may also be involved. Ownership, renewal, access, and support arrangements should be recorded clearly.
Ownership depends on the agreement and account setup. Lowveld Web states that clients own their content and agreed site deliverables, while hosting and access details are confirmed in the proposal.
Before a project begins, confirm who owns the domain registration, content, design deliverables, code, third-party accounts, licences, and hosting account. Make sure access and renewal responsibilities are documented. The answer can differ between a standard managed package, a custom build, and an externally hosted site.
SSL helps encrypt the connection between a visitor’s browser and the website. It is an expected basic security measure for modern sites, especially where forms, logins, or payments are involved.
A secure HTTPS connection helps protect information in transit and avoids browser warnings that can reduce trust. SSL does not by itself make an entire website secure, and it does not replace secure passwords, updates, backups, access controls, or safe development practices. The correct certificate and setup depend on the hosting and application environment.
Backup frequency should match how often content and customer data change and how serious the impact of losing recent information would be.
A brochure site with rare updates may have different backup needs from an ecommerce store, portal, or application with daily records. Backups should be protected, tested, and retained for an agreed period. A backup is only useful if it can be restored, so recovery procedures should be considered part of maintenance planning.
Maintenance may include agreed content updates, platform or dependency attention, security checks, troubleshooting, and practical improvements.
Maintenance is not identical for every site. A WordPress website may need updates and compatibility checks. An ecommerce site may need product, checkout, and order-flow attention. A custom system may need monitoring, user access management, bug fixes, and controlled releases. The exact scope, turnaround, and exclusions should be confirmed in the service agreement.
The host should be checked for current WordPress-compatible PHP, database and HTTPS support, plus practical backup, access and update arrangements.
Hosting details can feel technical, yet they directly affect whether the redesigned site can be maintained safely and predictably. The review should confirm the supported PHP and database versions, HTTPS, server limits, backups, access controls, and compatibility with the intended theme and plugins. If the current environment falls short, the recommendation should explain the risk and the available options plainly. The sensible next step is to have the hosting environment reviewed before development is committed.
Yes. A safer maintenance process uses a staging environment, current backups, focused tests, approval, and a documented rollback path before higher-risk changes reach production.
Routine updates should not feel like a gamble, especially on a site that receives enquiries or takes payment. WordPress advises taking a backup before upgrades, and a disciplined staging process lets the team test compatibility and key customer journeys first. A rollback plan should say what will be restored, who can approve the decision and how customers will be kept informed if needed. The sensible next step is to agree which changes require staging and what evidence is needed before they go live.
Prepare the new environment, map important URLs, use appropriate redirects, test key journeys, plan the cutover and monitor traffic, errors and Search Console after the move.
A hosting or domain move can feel risky because it touches the website’s availability, customer journeys and search history at once. Google recommends thorough preparation, URL mapping, permanent redirects where URLs change, testing and monitoring during a site move. The plan should also cover DNS, email dependencies, backups, rollback decisions and who watches for problems after cutover. The sensible next step is to request a written migration runbook before any production settings are changed.
An API is a controlled way for one software system to request information or actions from another system.
For example, a website may use an API to send a form enquiry to a CRM, retrieve product information from an inventory system, create a payment request, or display data from another service. An API is not automatically safe or suitable; access permissions, authentication, data handling, rate limits, errors, and ongoing provider changes must be considered.
Potentially, if the system provides a suitable API, webhook, export, integration tool, or other supported connection method.
The feasibility depends on the systems involved, the data that must move, the direction of the connection, authentication, permissions, error handling, and the provider’s terms or technical limits. A discovery process should map what happens when a form, order, payment, booking, or customer update occurs before any connection is built.
A webhook is an event notification sent from one system to another when something happens, such as a new order, payment, form submission, or status change.
An API often involves one system asking another for information. A webhook lets the source system notify a receiving endpoint when an event occurs. Reliable webhook handling needs signature verification where available, replay protection, validation, logging, retries, and a clear response when processing succeeds or fails.
A form can often send notifications to email, create a record in a CRM, or start another workflow, but the exact options depend on the tools and permissions available.
The form should be designed with a clear purpose and should collect only the information needed for that purpose. Integrations should handle spam, validation, consent, duplicate submissions, failures, and access to customer information. WhatsApp links and WhatsApp API messaging are different solutions and should not be treated as interchangeable.
Automation can reduce repetitive administration, but it should be designed with appropriate human review, exception handling, and accountability.
Good automation moves information between systems, sends routine notifications, creates records, or highlights tasks that need attention. It should not silently make high-impact decisions without an agreed process. Teams need visibility into failures, a way to correct errors, and access controls that prevent unauthorised actions.
The endpoint should verify the provider’s signature using the correct secret before acting on a message, with a documented, secure process for changing that secret.
A webhook can trigger real business actions, so it is reasonable to ask how the system will distinguish a trusted event from a forged request. Stripe’s guidance, for example, describes signature verification and secret management, but each provider’s method must be implemented according to its documentation. Secret rotation should be planned so it does not unnecessarily interrupt valid events. The sensible next step is to request a short security design for verification, secret storage, rotation and failed checks.
Design the receiving system to identify repeat events, process actions idempotently where possible, record event state, and cope safely with events arriving in an unexpected order.
Duplicate records can create genuine operational pain, from repeated emails to incorrect orders or jobs. Providers can deliver the same event more than once and may not guarantee order, so reliable integrations need more than a basic connection. The implementation should define how events are identified, stored, retried and reviewed when something does not line up. The sensible next step is to agree the duplicate and out-of-order handling rules using real examples from your workflow.
Use proportionate rate limits, abuse detection, validation, monitoring and provider-side spend controls to reduce the risk of service disruption or unexpected downstream charges.
It is sensible to ask about abuse before an automated feature reaches the public internet. OWASP describes unrestricted resource consumption as a risk because requests can consume bandwidth, computing capacity or paid downstream services such as email and SMS. The right protections depend on the feature and legitimate usage patterns, so they should be chosen and tested rather than copied blindly. The sensible next step is to identify the costly or sensitive actions and set clear limits, alerts and escalation ownership.
Treat external data as input that needs validation, mapping, error handling and review rules before it changes important business or customer records.
A connected system may be trusted commercially, but its data still needs practical safeguards before it changes your records. OWASP cautions against giving third-party API data weaker validation than user input, and the integration should make failures visible rather than silently creating bad data. Teams also need to agree what happens when a field is missing, malformed or inconsistent with the destination system. The sensible next step is to document the data mapping, validation rules and exception queue before the integration is released.
Agree what is monitored, how issues are detected and reported, who investigates, who approves business decisions, and how urgent cases are escalated.
Support expectations are clearer and calmer when the team does not have to invent them during an outage. A managed integration should identify its monitoring, visible error handling, communication cadence and the responsibilities of the business, provider and any third-party platform. The appropriate response time and escalation route depend on the operational impact, so they should be agreed rather than implied. The sensible next step is to include an incident and support schedule in the integration proposal.
Start with the least data needed for the stated workflow, document where it moves and rests, and make ownership and access responsibilities explicit.
Automations often make useful work faster, but they can also move customer or operational information across several services. It is responsible to ask what data is essential, which system stores it, who administers access and how it will be removed or retained. Cloud shared-responsibility guidance is a useful reminder that infrastructure providers and customers have different duties, particularly for data and access policies. The sensible next step is to create a simple data-flow and responsibility map during scoping.
Consider a new system when duplicated data, version confusion, manual hand-offs, reporting delays, access problems, or repeated errors are slowing the business.
Spreadsheets can be useful at an early stage. A database or application becomes more valuable when several people need reliable shared records, customers need controlled access, managers need current reporting, or a workflow requires repeatable rules and notifications. The first step should be mapping the real workflow, not automatically building a large system.
A business web application is a browser-based system that gives staff or customers controlled access to specific workflows, records, dashboards, or services.
Unlike a normal marketing website, a web application usually has authenticated users, data entry, business rules, records, dashboards, or role-based access. Examples may include client portals, job tracking, quoting, inventory, reports, booking workflows, or internal operations tools. Users normally access it through a browser without installing a traditional mobile app.
Choose based on how users work, whether they need device capabilities, how often they use the system, and whether app-store distribution is necessary.
A web app can be easier to access across devices and may be simpler to update. A mobile app may be appropriate when users need frequent mobile access, camera or location features, offline workflows, push notifications, or an app-store presence. The decision should follow the workflow and user needs, not the assumption that a mobile app is always more advanced.
A client portal can be designed so authenticated users see the records and actions permitted for their account.
A portal needs account creation or invitation, authentication, password or access recovery, authorisation rules, data separation, audit considerations, and a process for disabling access. The system should expose only what each role needs. Requirements for personal information, documents, payments, and staff administration should be discussed during discovery.
Yes, the first step is to understand the current records, process, roles, reports, integrations, and pain points before designing the database.
A database project may include data modelling, importing or cleaning existing records, forms, search, permissions, reports, backups, and connections to other systems. Existing spreadsheets or tools should be reviewed carefully before migration. The aim is to create a reliable source of information and a practical process, not merely to move the same confusion into a new interface.
The better fit depends on whether the workflow, data model, integrations, security needs and future change requirements can be met safely by a configurable platform.
This decision deserves care because both approaches can be useful in the right setting. A configurable or low-code platform may suit a standard workflow and existing data environment, while custom development can make sense where the process, customer experience or integration need is genuinely specific. The choice should be based on evidence from the work people do, not a preference for complexity. The sensible next step is to document the essential workflow and evaluate both options against the same requirements.
Document the current process, trigger, inputs, decisions, exceptions, approvals, outputs, owners, handovers and the result that proves the task is complete.
A vague app request can hide important operational detail, and it is understandable if the team has never written the workflow down formally. The goal is not to produce a perfect specification alone; it is to reveal where work starts, who decides, what happens when information is missing, and how success is checked. This gives the project a firmer basis for scope and acceptance testing. The sensible next step is to map one high-value process with the staff who do it every day.
Define the real user types, the records each can access, and the actions each can take, then apply the least privilege needed for their role.
Roles become important quickly when a portal serves customers, staff, managers and administrators. A useful design does not assume that everyone needs the same access; it identifies what each person needs to view, change, approve or manage in order to do their job. This protects sensitive information and keeps the interface simpler for ordinary users. The sensible next step is to create a role-and-permission matrix before screens and database rules are finalised.
The portal needs server-side authorisation rules that verify the signed-in user is allowed to access each requested record, not simply a hidden button or menu.
This is a fundamental trust question for any portal that holds customer information. The system should treat every request as needing an authorisation check, because changing an address or identifier in a browser must not reveal another customer’s data. OWASP identifies this kind of horizontal privilege issue as a serious access-control risk. The sensible next step is to make customer-data separation a documented test case, not just an assumed feature.
Assess multi-factor authentication according to the sensitivity of the data and risk, and agree proportionate controls such as throttling, lockout handling and secure recovery.
Account security is rightly a concern when a portal holds personal, financial or operational information. OWASP recommends multi-factor authentication where possible and describes the importance of defences against repeated login attempts, but the implementation should also consider how legitimate users recover access. The process needs clear ownership so staff know what happens when an account is challenged or locked. The sensible next step is to document authentication, recovery and support requirements before the portal is built.
Plan reasonable technical and organisational safeguards around access, data minimisation, encryption where appropriate, authentication, retention, incident handling and accountable ownership.
Handling customer information brings a responsibility that should be addressed before the system is built, not after it goes live. The Information Regulator’s POPIA guidance discusses reasonable safeguards and practical measures such as access controls, encryption and multi-factor authentication, but the appropriate approach depends on the processing and risks involved. A software team can help turn requirements into technical controls, while legal or compliance advice may still be needed for the organisation’s circumstances. The sensible next step is to identify the personal information, purpose, people with access and safeguards during discovery.
The Information Regulator says a Personal Information Impact Assessment should be undertaken early for a new project or processing activity; obtain appropriate compliance advice for your circumstances.
It is wise to raise privacy questions while the system can still be designed around them. The South African Information Regulator describes a PIIA as an early-stage exercise for a new project or processing activity, helping the responsible organisation identify privacy risks and safeguards. A development project cannot itself certify legal compliance, and the organisation may need specialist legal or compliance input. The sensible next step is to assign the responsible internal owner and schedule the assessment during discovery.
An audit trail should record the event, actor, timestamp, affected record, action and relevant before-and-after context, with access to the log itself controlled.
When a record changes or an approval is questioned, people need a reliable way to understand what happened. The correct audit trail depends on the workflow and sensitivity of the information, but it should be designed to support accountability rather than become an unmanageable collection of data. OWASP notes that inadequate access-control logging can leave violations undetected or unattributable. The sensible next step is to list the decisions and changes that genuinely need evidence, then agree retention and access rules.
If work happens away from reliable connectivity, offline behaviour should be considered early because it affects data capture, storage, user expectations and the system architecture.
For field teams, a mobile app that fails at the point of work can create more frustration than it removes. Android’s offline-first guidance makes clear that offline reads and writes require deliberate choices, particularly when staff must capture information before reconnecting. Not every workflow needs full offline capability, so the decision should follow the real conditions staff face. The sensible next step is to identify which tasks must continue without signal and what information can wait.
The application needs explicit rules for queued changes, retries, sync status, conflict detection and the authority that decides which valid update should prevail.
Offline capture is only helpful if people can trust what happens when the device reconnects. Synchronisation can involve delayed writes, retry queues and conflicts where two people changed the same record, so the system should make the status and resolution process understandable. Android’s guidance treats these as design requirements rather than a background detail. The sensible next step is to work through real conflict examples with the people who will use the app before development starts.
Apple requires accurate App Store privacy information about data collected by the app and relevant third-party partners, so the disclosure needs input from the whole product team.
App privacy disclosure can feel administrative, but it is part of being open with people about how their information is handled. Apple’s App Store guidance makes developers responsible for accurately declaring data practices, including relevant third-party partner and SDK activity. The disclosure should be based on an evidence-led inventory, not assumptions about what a library collects. The sensible next step is to create a data inventory and review every third-party SDK before submission.
Create role-based test cases that attempt permitted and prohibited actions, including access to another customer’s records, and record the results before release.
It is reassuring to have permission rules on paper, but they need evidence in the working application. OWASP recommends testing authorisation logic through unit and integration testing, and permission checks should be repeated after significant changes. Testing must include negative cases: what a user must not be able to view, edit, approve or download. The sensible next step is to include a permissions test matrix in the acceptance criteria and launch checklist.
Yes. Lowveld Web provides website design and related digital services for businesses in Nelspruit/Mbombela and the wider Lowveld.
The Nelspruit/Mbombela service area includes website design, redesign, ecommerce, SEO, custom software, databases, business web applications, and mobile-focused workflows. Collaboration can take place remotely by phone, WhatsApp, email, and online communication, with the project scope agreed before work begins.
The current service-area pages cover Nelspruit/Mbombela, White River, Sabie, Graskop, Barberton, and Hazyview.
Lowveld Web works remotely with businesses across the region. The right service depends on the business type and goal. Tourism and hospitality projects may need enquiry or booking journeys, while local service businesses may need lead-generation pages, and growing organisations may need ecommerce or internal systems.
Yes. Collaboration can take place through phone, WhatsApp, email, and online project communication.
Remote delivery can still include planning, content review, design feedback, testing, launch preparation, and handover. Clear communication, agreed scope, accessible files, and timely feedback are important. A client does not need to operate from a walk-in office to work effectively with Lowveld Web.
The usual path is planning, discussion, building, testing, and completion, with scope and next steps agreed along the way.
Planning clarifies the users, goals, pages, content, and features. Discussion aligns the vision, budget, and timing. Building turns the agreed structure into the website or system. Testing checks devices, forms, links, performance, and important flows. Completion covers launch, handover, and practical guidance for the next stage.
Explain the business goal, current problem, users, and desired next action. Lowveld Web can help identify whether the right next step is a website, redesign, SEO, store, portal, database, app, or integration.
You do not need to choose the technical solution before starting the conversation. A business may describe symptoms such as lost enquiries, spreadsheet confusion, manual order handling, slow updates, or difficulty managing customer access. Lowveld Web can then recommend a practical scope and distinguish between a simpler process improvement and a custom build.