TernoTechnologies Help Centre
We are based in one of the fastest-growing digital cities in the UK, Leeds.
Once we are finished with your website or application, we hand over the controls to you. However, we like to maintain regular contact to ensure you’re happy with our services and quality. If you need any additional help, we can discuss maintenance and upgrading options for your business.
This depends on what you’re looking for in a project. We set prices on the project scope, the time it will take and the technological expertise it will require. We are happy to discuss price options in a free consultation over the phone or in-person (if you’re based in Leeds).
Of course! We like to maintain contact with our customers and understand how our services have helped your business. Therefore, if you had a website designed and need maintenance, we are here to continue to support you.
As with the apps, depending on the complexity of your website, the design and coding, it may take up to 7 working days.
Yes, we would love to help revamp your website. We would first like to talk to you, get to know your business and branding then produce some design options for you to select from.
We evaluate the result after every two weeks, we test our work (we conduct both development and acceptance tests), we present it to you, we apply your feedback so you know you get what you are paying for.
A Peer Review practice is a part of our standard development process. Any code developed by an application resource is always verified by another application resource. Only after verification is the software released for testing. This practice is applicable only when the customer hires more than one developer.
Not exactly a demo version but using Agile Methodology, we are able to create operating software as soon as possible then add features as we move along the timescale planned for your project. Therefore, you will be able to examine and test your software very early on in the process.
While we feel that providing comments for all public methods is a good habit, we comment only when it is “truly required”. For instance, we avoid commenting on codes that have the correct method name. Through this practice, we avoid over-commenting and create codes that are easy to edit in the future if need be.