FAQ
Answers before you begin
Frequently asked questions about IT support, security, development, digital advertising, photography, video and virtual tours. Learn how to prepare, what each service includes and how results are assessed.
Getting started
Start with the situation and the outcome you want: what is getting in the way of staff, customers or sales, which systems you use and what needs to change. One concrete example helps, such as an order copied manually between systems or an application that repeatedly stops working. We can then discuss maintenance, an assessment, an integration or development. You do not need a complete technical specification for the first enquiry. Our service directory outlines the options; the scope depends on your environment.
Describe the main goal, the current problem and its effect on your work. Include system names, your website address, an approximate number of users or workstations, and any timing or budget constraints. For development, examples of required features and available content are useful. Identify who will make decisions on your side and who maintains the existing system. Do not send passwords, API keys or customer records through the public form. We will agree the necessary access and its transfer once the task is clear.
Yes. Responsibilities can be divided around specific systems and tasks. Your specialist might manage employee accounts while we look after agreed servers or an integration. Before work starts, we need to identify system owners, people who approve changes, access rights and the process for handing over issues. If a fault affects several systems, shared diagnostic information and a clear next action are important. The scope of managed IT services can complement your team’s role; another supplier’s contract and commitments are not automatically transferred to us.
The questionnaires help organise your situation: what is already defined, what information is missing and what to discuss with a specialist. After entering your email address, you can view a result based on your answers and receive a PDF report. Self-assessment does not replace a technical inspection, a security audit or a compliance assessment. If you select an additional website URL check, its scope and limitations are stated separately. Mark unknown answers accordingly. The questionnaire does not set a final price, and you can enquire without completing it.
Scope, pricing and timing
Pricing depends on the page structure, design, languages, content preparation and required features. A service website involves different work from a site with registration, data imports or connections to other systems. When planning website development, first agree the purpose of each page and what a visitor should be able to do. Content migration, additional copy or visuals, paid licences and maintenance after launch need to be identified separately. This makes proposals comparable by their scope as well as their total price.
The project price covers the agreed development, installation or change. Running the solution may involve separate costs such as hosting, a domain, software licences, storage, paid APIs or ongoing maintenance. These requirements and payment responsibilities should be discussed before choosing a technology. A backup solution, for example, may involve separate storage, licensing and administration costs. The proposal should distinguish included work, third-party charges and recurring expenses so that the initial implementation cost is not mistaken for the full cost of operating the solution.
Timing depends on the scope, the information available, integrations and dependencies on other suppliers. The plan needs to include content preparation, decisions, testing and acceptance as well as implementation. We identify the information and approvals needed from your team. If you have an important launch date, mention it at the start so that phases and first-release priorities can be considered. A specific schedule is agreed after these conditions are assessed; the service name alone is not enough to establish a reliable completion date.
We first compare a new requirement with the agreed scope and acceptance criteria. An agreed feature that does not work correctly needs to be distinguished from an additional feature or a changed business process. For extra work, we assess the effect on cost, timing, testing and other parts of the system. You can then decide whether to include it now, replace a lower-priority task or plan it for a later phase. In custom software development, an explicit priority list keeps the initial outcome and the remaining work clear.
IT infrastructure and security
Managed IT services are planned around your workstations, accounts, network and agreed systems. The plan describes user support, updates, monitoring and recurring tasks, together with responsibilities retained by your team or another supplier. New infrastructure, major migrations, security audits and software development are not automatically included. Before the service starts, we confirm the managed assets, responsible contacts and support process. That inventory makes everyday responsibilities clear and identifies work that needs a separate scope or project.
Support hours and response conditions are defined in the specific proposal. An automated alert may be recorded at any time, but that does not by itself mean a specialist is continuously on duty. We separately agree response targets, incident priorities, contacts and authorised actions. Response time also differs from resolution time: a fix may depend on an application developer, replacement equipment or your approval. If your operations require a particular support arrangement, it needs to be discussed before maintenance begins.
Server administration covers the agreed operation of existing servers and services: their condition, updates, resources and faults. An infrastructure project is appropriate for a new environment, a major redesign, equipment selection or a migration involving several systems. The distinction depends on the intended outcome, not only on the number of servers. We assess the current environment, business requirements and acceptable downtime first. Project handover and subsequent everyday administration are defined separately.
A scanner produces technical signals about selected assets; those signals still need validation and interpretation. An IT security audit starts with agreed criteria, scope and evidence requirements, and its conclusions must be supported by the information gathered. Penetration testing is not automatically part of that scope and requires a separate agreement on methods and permissions. An audit report is also not an organisational ISO certificate or confirmation of every compliance requirement. Explain at the outset which decision or requirement the assessment needs to support.
A SIEM is technology used to collect and analyse security data. A SOC service also involves a working process: which alerts are assessed, who decides their priority, who receives the information and who is authorised to act. Dev4you.lt uses Wazuh for security monitoring; sources and rules are selected for the environment. Specialist availability, escalation, permitted actions and log retention must be agreed before the service starts. Forwarding an alert does not automatically include a complete incident investigation, remediation or system recovery.
Identify the data and systems your operations depend on, how much recent data loss would be acceptable and how quickly work needs to resume. These requirements guide backup and recovery planning: storage locations, retained history, access, responsibilities and recovery tests. A successful backup message alone is insufficient; selected data or an application also needs to be restored and checked. The service covers agreed systems and available backup copies. Laboratory recovery from physically damaged disks is outside this service’s scope.
Website maintenance includes agreed updates, functional checks and fixes. A security assessment has a separate purpose, tested assets, methods and findings report. Its scope and authorisation must be agreed before testing; providing a website address is not permission for active tests. Confirmed issues can be included in separately agreed remediation and checked again afterwards. The report identifies untested areas and limitations, so its findings cannot be treated as an unconditional guarantee that the entire website is secure.
Development and integrations
A website usually presents services, provides information and generates enquiries. An online store needs a catalogue, checkout, payments, delivery and order management. Custom software is appropriate when a specific workflow, self-service process or permissions model cannot be adequately supported by a standard product. We start with what users need to do and the tools already available. Sometimes configuring an existing product or connecting systems is sufficient. Building from scratch should follow an assessment of its value and the ongoing maintenance it will require.
Yes. The first phase can complete one important process from beginning to end. For example, an employee submits a request, a responsible person approves it and the outcome is recorded. Before development, we define user roles, necessary data, error scenarios and acceptance criteria. Later features remain on a prioritised list and can be planned using feedback from actual use. A smaller scope still needs appropriate security, testing and handover; these are part of the first working version too.
Yes. Dev4you.lt develops apps for both platforms and has the developer accounts and licences needed. Before selecting a technology, we discuss users, device capabilities, offline use and connections to other systems. APIs, administration tools and release preparation are included according to the project’s needs. We separately agree who will own the publishing accounts and how access and project materials will be handed over. Submission to App Store or Google Play is part of the process, but we cannot guarantee a platform’s final approval or its date.
This depends on the interfaces and data exchange permitted by both systems. We initially need system names and versions, API or import documentation, and an example of the information to be transferred. We agree which system is the main source of each data item, how often transfers occur, and what happens after an error or duplicate record. Alternative transfer methods can be considered if an interface is limited, but universal compatibility cannot be promised. Paid API conditions, supplier permissions and ongoing integration maintenance are discussed separately.
Before changing the structure, existing URLs are collected and mapped to pages that will remain, move or be combined. Changed addresses need redirects to relevant content, alongside checks of internal links, indexing settings and migrated material. Existing search data, where available, helps identify priority pages. Errors and visibility changes should be monitored after launch. This preparation reduces the risk of migration mistakes, but it cannot guarantee unchanged rankings or traffic because search performance also depends on factors outside the website project.
Handover and ongoing care
The handover list is agreed for the project. It may include administration access, usage instructions, configuration and integration documentation, test results and outstanding work. If your team will edit content, we define in advance which pages and fields it can manage, the permissions needed and how those actions will be demonstrated. Handover includes checking agreed user tasks. Not every technical change becomes an editable content field, so we distinguish everyday content management from changes that will need a developer.
Code ownership, usage rights and the transfer of data and project files are defined in the contract. Work created specifically for your project needs to be distinguished from third-party software, templates, plugins and subscription services, which may have their own licences and renewal conditions. Before work begins, we discuss ownership of the domain, hosting, app publishing and other important accounts. The access and licensing handover list should make clear what you can administer yourself and what will need to be renewed or transferred.
Takeover is assessed against the technologies, access, documentation, licences and known problems. For a website, this includes the condition of its components and whether the code can be maintained; for an IT environment, it includes systems, equipment and responsible suppliers. Missing access or unsupported software is identified before specific responsibilities are accepted. Initial remediation is distinguished from ongoing maintenance. At the end of the takeover, we confirm the managed assets, open issues and responsibilities so both sides know what is covered.
The responsible team and maintenance scope should be identified before launch. We can discuss recurring updates, functional checks, issue reporting and further improvements, but these are not automatically included in every development project. The agreement needs to distinguish fixes to agreed functionality, new requirements and the effects of third-party changes. Support channels, availability, access and your responsibilities are also defined. If your team or another supplier will provide maintenance, the agreed documentation and administration information are included in handover.
Marketing and advertising
We first agree which visitor action matters: an enquiry, a booking, a purchase or another verifiable outcome. We then assess landing pages, forms, analytics and the integrations needed to support it. Work can be coordinated with your marketing specialist, with clear responsibilities for strategy, content, advertising and technical implementation. Advertising spend, specialist work and creative production are discussed separately. Reporting should show the agreed actions and the limits of the data. We do not promise specific search rankings, sales or a guaranteed return on investment.
We first clarify what you offer, which areas you serve and which requests you cannot accept. During the campaign, we review available search terms, ad copy and the pages visitors reach. Negative keywords can help exclude unsuitable searches, but an overly broad restriction may also remove relevant demand.
Your team's feedback on actual enquiries therefore matters. The solution may involve changes to ad settings or clearer service boundaries on the website. We assess the relevance of enquiries rather than treating a lower cost per click as the only sign of improvement.
That depends on the offer and the action visitors should take. An ad should communicate a clear benefit, and the destination should make the matching information easy to find. A general page may be suitable if the offer and next step are clear; a dedicated landing page is assessed separately.
We plan creative variants to compare a specific idea, such as different ways of presenting a product, rather than simply producing more files. Before launch, we agree the variants, check the mobile presentation and test the enquiry path. New content or page development is scoped separately.
We first assess whether the existing footage can clearly show one offer: a product in use, a service process or an answer to a customer's question. Simply shortening the film may not be enough. The opening, format, on-screen text and destination after the click need planning.
Suitable footage can be edited into agreed variants; missing material may require separately scoped production. The permitted use of footage and music is agreed before use. Preparing the video, publishing an organic post and managing a paid campaign are identified as separate parts of the proposal.
First, we assess what is ready and what is still missing. Alongside the amount paid to the advertising platform, the project may require campaign setup, management, copy, images, video, measurement or website changes. The proposal separates these elements and identifies which tasks your team will handle.
Sending more traffic to a broken form or an unclear offer does not solve the underlying problem. Budget limits and approval of additional work are agreed before launch. There is no universal allocation: it depends on the channel, available content and the website's current condition.
We first check what each system counts as an enquiry. Clicking a button or starting a form is different from a message accepted by the server. We check for duplicate events, failed submissions recorded as successes and mismatched reporting periods.
Differences may remain because of channel attribution, consent settings and data coverage. These need explanation rather than adjustments made simply to force the figures to match. Reporting also distinguishes successful technical receipt from an enquiry's relevance to your business; your team's feedback on actual contacts helps assess the latter.
The offer, audience and market, budget limits, suitable creative material and the path to an enquiry or purchase need to be agreed. If accounts already exist, their history is useful; access is granted through account roles rather than passwords sent in an enquiry form. We also identify who approves copy and visuals, responds to enquiries and authorises changes.
Before launch, we test the agreed measurement events and the mobile website experience. Missing content, product data or technical work is added to a preparation plan with clear responsibilities, rather than being left unresolved at launch.
Photography, video and virtual tours
The brief can cover company, product, team, interview or social media content. We start with the purpose, audience and intended channels: a website, an advertising campaign or several channels may require different formats. The proposal describes the final deliverables, preparation and revision scope. Usage rights, music, necessary permissions and any transfer of raw material are agreed separately. This makes clear which files you will receive and where you can use them. Additional filming or a new script is not automatically included as a revision.
Choose a promotional video when you need to explain a specific product, service or offer and show viewers what to do next. A corporate film gives more room to explain the business, its working processes and its value to clients or partners. For an enquiry, identify the audience, central message and viewing channels; these guide the story, footage and versions.
Existing material can be assessed for the intended brief. Production scope is agreed for either format, while managing an advertising campaign is a separate part of the work.
Yes. A corporate story can use footage of the business, on-screen text, voice-over or a combination. We first agree what viewers should understand, such as the product journey, a quality check or how a service is delivered. This informs the shot list and the facts your team needs to approve.
Voice-over, graphics and language versions are included according to the agreed scope. The setting also matters: an exhibition film may need to work without sound, while a website or sales meeting calls for different presentation. Your representative confirms the facts and what can be shown publicly.
A virtual tour connects panoramic images through clear navigation points. Names and information panels are planned to keep the scene visible, and controls are checked on mobile and desktop. Website integration is chosen after reviewing your site; a preview with visitor-initiated loading can be considered.
A written description of the space and a contact route remain available without using the tour. Before ordering, we discuss hosting, access, any recurring charges and future updates. A panoramic tour does not automatically include a three-dimensional model or measurements of the space.
Prepare the agreed spaces, products and props, arrange access and nominate someone to coordinate work on site. If team members are taking part, discuss their preparation and roles beforehand. Use the shot plan to check visible branding, screens and documents so confidential information stays out of the picture.
For 360° photography, the entire surrounding area matters, including mirror reflections. Provide brand guidelines and approved facts as well. Operational premises, outdoor conditions and areas that are not ready can affect production arrangements, so these circumstances should be discussed before the shoot.
A shared shoot can be planned with separate final versions for different channels. Identify the intended placements before production: vertical and horizontal video need different composition, text positioning and framing of important details. We agree whether shorter edits, alternative openings, languages, voice-over or subtitles are needed.
Cropping a finished horizontal clip may not be enough. Delivered files are labelled by purpose, with exports prepared for the agreed use. Usage rights and the scope of additional versions are clarified separately, so include the channel list in your initial brief.
Raw footage and editable project files need to be included in the agreement before work begins. Ordering a finished video does not automatically include every recording and editing file. If your team or another creator will make future changes, explain this in the brief so the required files, availability and storage arrangements can be discussed.
Music, voice-over, graphics and other included material also need agreed usage conditions for the intended channels. Access to working files and permission to use their contents are separate matters; both should be clarified as part of the project agreement.
From a question
to a clear task
For the first conversation, describe your current situation, the main outcome you want and the systems you use. If you have technical documentation or an example of the problem, explain what needs to be assessed.
We use this information to define the scope, your team’s and our responsibilities, and a result that can be checked. We discuss timing, access and any additional services before work begins.
- Clear scope
- A result you can check
Couldn’t find the answer you need?
Tell us about your situation and we will help clarify where to start.