Knowledge base for clients

new – the subscription is yet to be activated.

pending – there was an activation attempt, but the payment did not go through or is being processed.

active – you’re good to go!

This is done from your app.lemon.io dashboard by making an initial payment for 1 month/week of work within the agreed-upon estimated workload.

The estimated weekly/monthly number of hours is discussed and agreed upon during the hiring process. For developers employed full-time, it is 40/160 hours; for part-time work, it is 20/80 hours or more. Please get in touch with your personal Customer Success Manager via email if you wish to change the estimate.

Onboarding may begin as soon as you activate the developer’s subscription from your app.lemon.io dashboard. Once it is done, you will receive an intro email with their contact information and can start the ball rolling!

After making the initial payment, which both activates your subscription and is credited in full to your account balance, subsequent charges are based on the developer’s reported hours. Monthly billing occurs every first Tuesday, and weekly billing every Tuesday. Any unused balance will be refunded at the project’s conclusion

1. Visit https://app.lemon.io/dashboard, then select a subscription.
2. Click “Transfer Subscription”, and select who should be the new owner.
3. Done! New owner should add an active payment method, so there won’t be any pause in the developer’s work.

Payment card/bank transfer – payment replenishing the subscription balance charged from your account. Click the download sign on the right to see your receipt
Payment failed – unsuccessful charge attempt
Report – the number of completed work hours logged in by your developer. Click on the speech bubble icon on the right for a detailed breakdown of work/hours.

No extra steps are needed. We will include the extra hours in tuesday’s charge.

We will charge your card just for the number of hours reported.

Nope, since nothing was reported – the subscription balance remains intact, and thus you will not be charged on the upcoming tuesday.

You are only paying for the number of hours the developer worked. Since time off and sick days are not reported as work completed, they do not need to be compensated – just another bonus for going the freelance route.

You can pay with a credit/debit card, bank transfer, or ACH Direct debit (available for US customers only). Payments are processed via Stripe. You are charged every Tuesday, based on the number of hours completed by the developer. You have total control and are free to add/delete/change the payment method you would like to use from your app.lemon.io dashboard, “Billing” section. In case if you choose to pay monthly, you will be charged on the first calendar Tuesday of each month.

You can change default payment method by visiting the “Billing” tab on the app.lemon client portal.

Each charge is followed by an email receipt from Stripe, including the number of hours you are paying for. You can also access receipts from your app.lemon.io dashboard (the download icon is on the right of every transaction). Detailed developer reports can be found and downloaded as an editable file from your dashboard’s activity log (a useful tool to keep all the accounts in order).

With the activation of each subscription, you are assigned a personal Customer Success Specialist, your liaison with the developer and with Lemon.io. Think of them as a mix of a fairy godmother and Chip and Dale Rescue Rangers. They watch over each subscription to ensure things are going smoothly and are ready to help with any issues that may arise:

• They can answer any Lemon.io-related questions you have. Seriously, feel free to contact them if something is not clear or if you have any concerns.
• They will find you new developers to hire – Lemon.io way is the best way! Every second customer prefers to do future hires via our platform once they see the advantages and simplicity of the Lemon.io model. Your personal CS specialist knows your needs, expectations, and style, so they are sure to connect you with the crème de la crème of the developers for the newly open positions.
• They are here to fix any issues you have with your current developer. Issues like replacements, heart-to-heart discussions, and settling magic of forwarding your requests and critiques to the developers are all within the range of Customer Success responsibilities.
• They are here for your feedback. Lemon.io became so awesome and easy to use because our customers always loved to share their experiences. Letting your Customer Success buddy know what works or does not work for you gives us new tools to craft service and experience that exceeds all expectations.

To contact your personal CS manager, you can send them an email:
Malky – m@lemon.io
Andrew – abondar@lemon.io
Olha – o.ivasiuk@lemon.io
Anastasiia – anastasiia.c@lemon.io

Or you can book a call:

book a call with Malky via this link.
book a call with Andrew via this link.
book a call with Olha via this link.
book a call with Anastasiia via this link.

Don’t have your personal manager yet? Book a call via this link, and we will assign you one.

You can request to pause an active subscription from your Lemon.io dashboard by clicking “Request to pause” in the top right corner on app.lemon.io. Your Customer Success Specialist will reach out to you to confirm. 

Although we do prefer to be the connecting force between the developer and you, Direct buy out (we call it OptOut) can be considered. Please book a call or reach out to your Customer Success Manager for more details.

It would be preferable to have at least a two-week notice for subscription termination sent to your personal Customer Success Specialist. Once the work end date is set, we ensure that the developer has reported all completed work hours. If there is any outstanding balance on the subscription – it needs to be covered. If there are hours still remaining – they will be refunded. Once these matters are handled – the subscription will be closed.

Yes, you can! Navigate to the “Team” page and click “invite new member”. Make sure to assign the correct access type to your team member. Optionally, you can unsubscribe from email updates yourself on the profile -> notification settings page.

Yes, you can! Navigate to the “Team” page and click “invite new member”. Make sure to assign the correct access type to your team member.

There are 4 access types:

Account owner: this user has full access.
Admin: this user has full access, but can’t revoke the account owner’s access.
Read Only: this user can view reports from developers, but won’t receive billing updates. Mostly is granted to PM/tech lead, so they will be able to check developers’ reports.
Finance: this user will receive billing updates; can manage subscriptions and payment methods.

Yes, you can unsubscribe from all billing updates (and most of system emails) in profile -> email notifications. Some system notifications will still be sent to you (password change, etc.)

You can log in by clicking here. Then, log in via Google account or by email and password.

If you’re newer to working with software engineering talent, it can be daunting thinking that you’re their boss. Here are some questions to ask them to make sure things are plugging along:

Early-stage (weeks 1 – 3):

• Do you have access to all the tools, repos, and environments you need?
• Do you have all the documentation you need?
• Are you clear on what we’re trying to build and why?
• Any questions for me right now?

Mid-stage (weeks 4 – 8):

• Is the workload manageable?
• Are you getting enough feedback from me?
• How confident are you that we’re on track for our goals? What do you anticipate might slow us down?

Late-stage (weeks 10 – 12):

• What areas still need refinement or testing?
• How can I help get us ready for launch?

Developers really want to deliver great work for you, and these conversations help make that possible.

If you’re a few weeks into a project and unsure whether you’ve found the right fit, look for these signs:

• They aren’t afraid to show their work. Most love to walk you through all the challenges they’ve come across and how they’ve handled them. Some things may be tough to demo, but if they’re willing to explain what they’ve done, that’s a good sign.
• They aren’t afraid to ask questions about your requirements. This means they really want to understand what your expectations are. That way, they can more accurately estimate the time it will take to complete them.
• They share blockers. This means they’ve anticipated potential issues or are already deep in the development process, having hit a snag that requires your help.
• They offer ideas outside their immediate scope because they understand how everything connects, and they’ve probably built something similar before. For example, David Haddad, Head of Product and Technology, Adherium, said of his Lemon dev: “He’s been a fantastic thought partner, especially with ambiguous direction. He has been super helpful for the business and how we present ourselves.”
• They push back on unrealistic timelines. Not because they’re being difficult, but because they’re protecting your investment. Lissy Alden, founder of MYNDY, said of her Lemon dev: “I said upfront I wanted someone who wasn’t afraid of conflict, and wouldn’t be afraid to push back. He’s delivered on all fronts.” The best developers aren’t just executors, they’re collaborators.
• They follow agile methodology. They are used to daily standups, retrospectives, grooming, and planning sessions. This framework has been around for decades because it works. Devs who have a strong sense of agile are typically good self-managers.

When you ask, “Can we make this button do something different?” it may seem like a small change, but it could involve touching data models, APIs, and tests. And it’s not uncommon.

One dev shared: “A client assumed that adding a new AI model was basically just swapping a file, not realizing we needed data preprocessing, GPU tuning, and new inference endpoints to make it work.”

Another had a client who thought a complete redesign of an app should take a couple of days and wouldn’t require any additional changes to the codebase logic.

“In cases like that, I take that as a sign that I need to clearly explain the implications of tasks or changes that look simple on the outside but have more to them on the inside, since non-technical clients lack that context.”

Every adjustment has a ripple effect across your app. A clear scope and transparent change request process protect you (and your dev) from missed expectations and unplanned costs.

If you’re asking for a change mid-project:

A rushed “quick fix” can cause downstream bugs, break existing features, or force rework later. To make sure you really need this change:

• Confirm how long it might take, and whether that fits your release schedule.
• Make sure you have enough time for retesting and validation after each update.
• Ask what other parts of the system that change could affect downstream and what proactive steps the dev might need to take to prevent errors.

The more context you give them for why this change is necessary, the better they can balance flexibility with reliability.

Most backend work is invisible.

Nearly 70% of developers we surveyed said architecture and setup were things they wished clients knew more about. As one developer explained, “Most people understand what servers and web applications do, but it’s the architecture and infrastructure issues that are hard to grasp.” 

Things like logging, exception handling, uptime monitoring, API optimization, and database indexing don’t make for flashy demos. But they determine whether your app crashes under load or scales to meet the demands of your end users.

If setup is taking longer than expected:

Your dev is likely building a system that won’t need constant fixes later – and that’s a good thing! Ask your dev what long-term problems this setup is designed to prevent so you have a sense of what’s going on behind the scenes and why it’s important.

62% of the devs we’ve surveyed cite communication as the key to strong collaboration. But don’t go overboard.

When you schedule last-minute syncs, request urgent small changes, or ask for immediate responses on Slack, you’re fragmenting your developer’s focus. The work that might only take a few hours can easily stretch to two days when interrupted repeatedly. 

Our suggestion? Work with your developer to establish communication norms 

Set preferred channels, response SLAs, and check-in cadence in week 2 of your project, and stick to them. Consistency beats frequency.

As the team at Little Spoon put it: “With Lemon, we have access to engineers all over the globe. As long as they can hand off and exchange the information that we need to keep the machines running, I don’t care how they work, when they work, or where they work from.”

There’s a common tension in software development projects: clients want deliverables right away, but quality code requires proper testing, thoughtful architecture, documentation, and attention to detail.

Rushing these steps creates technical debt that will cost you more time and money down the road – especially if a new developer has to step in.

If your developer says something will take longer than expected:

Take it as a sign they’re building for stability and not taking shortcuts. Be curious: ask what tradeoffs they’re managing and what risks come with moving faster so you’re both on the same page. This is a generalization, of course, but most developers interpret curiosity as collaboration and interpret pressure as panic.

In the early stage of a project, a few days can pass without a single Git commit. While that might make you anxious, we recently surveyed our expert talent base, and over 38% of developers said 2 to 3 days without commits is normal. Another 31% said they sometimes go 4 to 7 days without a commit.

And it’s not because nothing’s happening. It’s because significant backend work, like environment setup and architecture tasks, takes uninterrupted time and doesn’t produce visible updates.

If you’re concerned about the work getting done:

• Ask if there’s anything you could do to help your dev achieve the results you want quicker. They’ll let you know if they have any questions or if any requirements are unclear.
• Schedule a brief weekly check-in and ask your dev to explain the work they’ve done, share key metrics they’ve hit, and highlight any upcoming blockers. That way, everyone’s on the same page.

If you’re short on time, request a daily or weekly async progress report on Slack, ideally with short Loom videos of the dev showing you progress.

At Lemon, we survey developers at weeks 2, 3, 4, 6, 8, 10, and 12 to catch early friction between clients and devs. These check-ins assess several key areas, including:

• Onboarding clarity
• Work schedule alignment
• Tooling comfort
• Workload manageability
• Communication quality

If anything seems off, our account management team steps in immediately to realign expectations. Reason being: when issues like unclear requirements, scope creep, and communication gaps are caught early, they can be resolved before they turn into bigger problems that build up resentment and frustration.

Borrow this technique for your own projects:

Simple questions like “Do you have what you need?” or “Is anything blocking you?” throughout a project build partnership and keep you in the know.Want to get a sense of how we work and what our devs are capable of? Check out our case studies.

Getting 80% of the way there is the easy part. The finishing touches – error handling, edge cases, mobile responsiveness, loading states, proper validation – take careful thought and separate a functional prototype from a production-ready product.

If your developer is slowing down near the end of a project:

Ask them to explain why. Chances are, they’ll tell you about QA, edge cases, and reliability work that protect you from future bugs and downtime – things that ensure everything is polished and doesn’t just look polished.
This is how one of our devs at Lemon handles finishing touches and expectation-setting: “If I can show a page without authentication, unfinished styling, and rough error-handling, I do, always alerting clients that all of those are not finished to set expectations. Then, each of my commits targets a missing piece. The client is thankful for the communication, and they see all of the pieces that make up a good UX experience in all senses.”