News

After Go-Live: 7 Things to Plan for Software Maintenance and Support

Launching a new website, web application or mobile app is an exciting milestone. But go-live is not the finish line. From the day real users start relying on it, software needs steady care to stay secure, fast and useful. Organisations that plan for this early avoid surprise outages, security gaps and costly rebuilds a few years later.

Here are seven practical things to plan for after your software goes live.

1. Agree on who looks after it

Decide clearly who is responsible once the project is handed over: your in-house IT team, the original developer, or a support partner. Write down who receives problem reports, who can approve changes and how urgent issues are escalated. When everyone knows the process, small problems get fixed before they grow.

2. Keep software and dependencies updated

Most modern systems are built on frameworks, plugins, libraries and server software that receive regular updates, many of them security fixes. Schedule time to apply these updates, test them first where possible, and keep a record of what changed. Outdated components are one of the most common ways websites and applications get compromised.

3. Back up data and test restores

Your database, uploaded files and configuration are often more valuable than the code itself. Make sure backups run automatically, are stored in more than one place, and are tested by actually restoring them from time to time. A backup that has never been tested is only a hope.

4. Monitor uptime, performance and errors

Do not wait for customers or staff to tell you the system is down. Simple monitoring can alert you when a site stops responding, when pages become slow, or when errors start appearing in the logs. Watching disk space, SSL certificate expiry dates and domain renewals also prevents some very avoidable outages.

5. Review security and user access regularly

Staff change roles and leave, and accounts are often forgotten. Review administrator and user accounts every few months, remove those that are no longer needed, and enforce strong passwords or two-factor authentication where the system supports it. Check that sensitive data is only visible to the people who genuinely need it.

6. Listen to users and plan improvements

Real-world use always reveals things nobody expected during development: a confusing form, a missing report, a step that takes too long. Collect this feedback in one place, group it, and plan small improvements in regular cycles rather than waiting for a large and risky overhaul.

7. Keep documentation up to date

Good documentation covers how the system is hosted, where the source code lives, how to deploy updates, which accounts and services it depends on, and how to restore it after a failure. Keeping this current means your organisation is not dependent on one person’s memory, and it makes any future handover much smoother.

Plan maintenance from day one

The best time to think about maintenance is before launch, when you are setting the scope and budget for a project. Including updates, backups, monitoring and support in your plan from the start keeps your software reliable for years instead of months.

Talk to eDruk

eDruk Private Limited has been building and supporting software in Bhutan since 2004, including websites, web applications and mobile apps. If you would like help reviewing an existing system or planning maintenance and support for a new one, get in touch with our team.

Email: edruk@edruk.com.bt
Phone: +975 2 332277
Website: www.edruk.com.bt

News

Reliable Wi-Fi for Offices, Schools and Hotels: 7 Things to Plan for Full Coverage

Slow or patchy Wi-Fi is one of the most common complaints in offices, schools, hotels and homes. Very often the internet connection itself is fine. The real problem is how the wireless network inside the building was planned. Thick stone or concrete walls, several floors and a growing number of phones and laptops can quickly overwhelm a single router placed in a corner. Here are seven practical things to plan for reliable Wi-Fi coverage.

1. Start with how the space is used

Before choosing equipment, walk through the building and note where people actually work, meet and connect. A conference room, a classroom or a hotel lobby may have many devices at once, while a store room may need almost none. Planning around real usage helps you place coverage where it matters instead of spreading it evenly and hoping for the best.

2. Respect walls, floors and materials

Wireless signals weaken as they pass through walls and floors. Traditional buildings with thick masonry, concrete slabs, metal roofing or mirrored glass can block Wi-Fi far more than lighter partitions. A quick site survey to check signal strength room by room shows where extra access points are needed, so you avoid dead zones after installation.

3. Use several access points, not one powerful router

A single router turned up to full power rarely solves coverage problems. Several properly placed access points, usually mounted on ceilings or high on walls, give more even coverage and share the load between users. When they are managed as one network, devices can move between rooms without losing their connection.

4. Plan the wired backbone too

Good Wi-Fi depends on good cabling. Each access point should ideally connect back to a network switch with a proper structured cable, and switches that provide Power over Ethernet (PoE) can power access points through the same cable. Planning cable routes, a tidy network rack and spare capacity at the start makes later expansion much easier.

5. Separate staff, guest and device networks

Not every device should share the same network. A common approach is to keep staff computers on one network, give visitors or guests a separate network with internet-only access, and place devices such as printers, cameras or smart equipment on their own segment. This keeps important systems safer and makes problems easier to troubleshoot.

6. Secure it from day one

Use current encryption (WPA2 or WPA3), strong passwords that are changed when staff leave, and change the default admin login on every router and access point. Keep firmware up to date, and avoid sharing the main office password with visitors when a guest network can do the job.

7. Test, document and maintain

After installation, test coverage and speed in every important area, not just near the equipment. Keep a simple record of where each access point is, how the networks are set up and who manages them. Regular checks and firmware updates help the network stay reliable as more devices are added over time.

Need help planning your wireless network?

eDruk Private Limited has been working on software and ICT solutions in Bhutan since 2004, including networking and infrastructure. Whether you are setting up a new office, upgrading a school or hotel, or fixing persistent dead zones, our team can help you assess your site and plan a network that fits your needs.

Email: edruk@edruk.com.bt
Phone: +975 2 332277
Website: https://www.edruk.com.bt

News

Planning a Software Project? 7 Things to Put in Your Brief Before Development Starts

Most software projects that go wrong do not fail because of the code. They struggle because nobody wrote down clearly, at the start, what the system was supposed to do, who would use it and what “finished” looks like. A good project brief fixes that. It does not need to be long or technical. It just needs to answer the right questions, so that you and your development team are building the same thing.

Whether you are planning a website, a web application or a mobile app for your organisation in Bhutan, here are seven things to put in your brief before development starts.

1. The problem you are solving

Start with the “why”, not the features. Describe the problem in plain language: paper forms that get lost, customers who cannot find information, staff re-typing the same data into several spreadsheets. When the problem is clear, a developer can often suggest a simpler solution than the one you first imagined.

2. Who will use it

List the different types of users: staff, managers, customers, partners, administrators. For each group, note what they need to do and how comfortable they are with technology. A system used mostly on mobile phones by field staff needs a very different design from one used at office desktops.

3. The must-haves and the nice-to-haves

Write your feature list in two columns. Must-haves are the things the system cannot launch without. Nice-to-haves can wait for a second phase. This one step does more than anything else to keep timelines and budgets realistic, because it lets you launch something useful sooner and improve it based on real feedback.

4. Data, existing systems and integrations

Note what data the system will store, where that data lives today and which existing systems it must talk to, such as accounting software, payment gateways, SMS or email services. Mention any data you already have in spreadsheets that will need to be moved across. Integrations are often the most time-consuming part of a project, so it is better to surface them early.

5. Security, access and privacy

Think about who should see what. Do different users need different permission levels? Does the system hold personal or financial information? How will data be backed up? Writing these expectations down at the start is far easier than adding security after the system is built.

6. Content, language and branding

Decide who will provide text, photos and documents, and whether the system needs to support Dzongkha as well as English. Share your logo, colours and any existing brand guidelines. Missing content is one of the most common reasons websites and apps launch late.

7. Life after launch

A system is never truly “done”. Plan for who will add content, manage users and handle day-to-day questions once it goes live. Ask how updates, security patches, hosting and backups will be handled, and what training your staff will need. Agreeing on this up front avoids surprises a few months later.

Keep it simple and keep it shared

Your brief can be a few pages in a shared document. What matters is that the people who will use the system help write it, and that it is reviewed with your development team before any design or coding begins. Expect it to change a little as you learn more; the point is to start from a shared understanding rather than assumptions.

Talk to eDruk about your project

eDruk Private Limited has been developing software in Bhutan since 2004, including websites, web applications and mobile apps, along with technical consultation to help organisations plan their projects. If you have an idea but are not sure where to start, we can help you shape it into a clear brief and a practical plan.

Email us at edruk@edruk.com.bt, call +975 2 332277, or visit www.edruk.com.bt.