And then, you get a customer asking you for something that could be implemented on your service, but it’s faster to do it manually, respond to the customer and close the ticket.

Often, this is misleading because this one, isolated, customer indeed was faster to process manually than to build the feature directly, but what you tend to forget, is that a few others will ask the same thing.

And when you stack all these requests, the time spent is longer than it would have taken to just implement that feature.

In general in my life, I try to apply the principle that if it takes less than 5 minutes to do, I’ll do it immediately.
This is not really helpful for the present “you”, but your future “you” will thank you.

You put your tools on the kitchen table, thinking “I’ll move them to the garage when I’ll have the time”, and things start to pile up. When you do it now, you have less clutter, and one thing less on your mind. Granted, you did one more trip to the garage, but hey, you did more steps today :)

That’s the same principle we are applying at Fernand; If it takes less than 30 minutes to implement, we’ll do it right away, because we believe that if one customer reaches out about a request, 10 others had the same request but never bothered to ask.

We recently had this scenario. Until now, it wasn’t possible to change who was the owner of an organization. To change that, you had to reach out to us and we would manually change the ownership in the database.

Clearly, this is a typical case of “it just takes less than a minute to update the database”, so it didn’t make sense to jump on developing the feature right away. On top of that, we have a massive roadmap and this request is not in the top priority.

But this customer wasn’t the first, and certainly not the last. On top of that, I discovered a sneaky problem: the one requesting to change ownership was not the owner, but someone else in the team. What if it was just a simple, bad intentioned employee ? They could be a new hire that tried to take over the account.

So I worked on that feature, and less than half an hour later, it was possible - for the owner only - to give ownership to another team member.

I told that user about the new feature and let them change ownership directly from their owner.

That’s one request we won’t have to handle anymore, giving us more time to work on important things.

Just to clarify things, Fernand is our latest project, a Help Desk SaaS with a focus on speed, efficiency, and calm. We were just two working on this, Antoine and me. Antoine is the designer and marketing specialist behind the voice of Fernand, and I'm the technical one.

This article is about the evolution of the technical side.

Fernand first started being built on Flask. I've been building all my recent projects using Flask and I've a pretty good grasp of how it works. ImprovMX, our other service, is running on Flask with a few modified internals specific to our needs. So it made sense to build Fernand using Flask too.

But while we were heads down on building it, we had a few issues on ImprovMX that was caused because some requests would take too long to complete. The issue is that when Flask accepts a request, it will block a thread for this request until it is completed. if that requests fetch a lot of data from the database and takes time, the thread won't be free for other users while waiting for the database results.

At that time, I was curiously checking the landscape to see if there weren't anything new I could use on Fernand rather than staying with the old (but reliable) Flask. I had seen FastAPI, Sanic, Starlette and a few others, and tried FastAPI and Sanic. What was interesting me was the A in ASGI: Asynchronous Server Gateway Interface. I had a clear vision that this would become handy, moreover because recent Python versions introduced the async keyword. It made sense.

After the downtime we had at ImprovMX, and once I discovered it was because some endpoints were slow (yes, I fixed them to improve their response time), it made sense for me to move over an ASGI framework.

Sanic was appealing to me. Firstly because it was tested as one of the fastest Python framework, but also because the way the codebase, and how the flow was done, was more how I think.

So here I was, migrating the whole Flask codebase to Sanic.

I'm not a fan of adding decorators on top of decorators, so having a :

@ratelimit(5)
@authenticated
@db
@app.get('/')
async def show(request):
    limit = request.args.get('limit', 20)
    return sanic.response.json(await MyModel.get_latest(limit))

Was absolutely not appealing to me.

So I rewrote how the routes were handled, and implemented a few ideas from FastAPI along the way. Now, you could do this :

@app.get('/', ratelimit=5, auth=True)
async def show(user, limit:int = 20):
    return await MyModel.get_latest(limit)

Way more cooler isn't it?

A few things to note from this:

1. There are no more "lots of decorators", all the properties are defined in the route ("@app.get"), which makes more sense - at least for me

2. The route doesn't impose the requestparameter anymore, and you can have the user parameter from the auth parameter, but it's optional (if you don't ask it, it won't be added in the function)

3. The request parameter is added if asked, and cast to the proper type if type hint is provided

4. The response is adjusted based on what is returned. I went a bit beyond what can be seen here, because it's possible to return a Model object, and it will be serialized based on more advanced code.

These two decisions, from using Sanic as the main framework, and rewriting the router to handle more parameter is the best decision we could have for a clear code base. I’m really happy with how things turned out :)

It allows you to send events that trigger a campaign with specific workflows and works wonderfully for many areas, such as onboarding, upgrades, and churns.

But there is also another way you can use Customer.io to improve your conversion.

I recently realized that it could happen that a few users on PDFShift would try to upgrade to a paid plan, but had issues because their card was refused (for a number of reasons). Up until then, this was left as-is, and if the user wouldn't retry again, I would not know about nor try to learn more about why they finally dropped it.

(When you think about it, that's kind of crazy. You have a user that is interested to pay for a product and tries to upgrade but their bank is refusing the payment, so they drop it and go somewhere else. You definitely need to have actions in place here to catch them before they leave! That seems so obvious when you think about it!!)

So here's what I did. I created a new campaign on Customer.io that would be triggered by an event, and every time a payment would fail on Stripe, I would receive a webhook event.

On my server, upon receiving that event, I would check if the payment is from a new customer (no previous successful payment), in which case I would send the event `first_payment_failure` to Customer.io.

(I have other actions set up when a recurring payment fails)

Then, over at Customer.io, I created a campaign based on that event's trigger, that would wait for a few hours (I choose 2 hours), then it would check if that user hasn't upgraded in between. If they are still a free user, I would send them an email asking them what happened, and how I can help.

Of course, the sender would be my personal email. That way, when they respond, they get into my inbox directly and I'm the one responding, which shows that I'm invested in helping them.

This doesn't bring too much work; it's not often that a user can't upgrade and decide to leave (thankfully) but when this happens, Customer.io has my back and I can still try to win that customer!

More broadly, you need to be aware of any areas where you could be losing a conversion (being a customer, a subscriber or anything else). If you can find a way to track them and then find ways to reach out to them to see how you could help, it could be a great way to show how you are motivated to help them, and it could make a difference. (Of course, never be too pushy or reach out if they haven't shared their email to you voluntarily).

Good luck :)

When you first release your code, you have a set of checks you've implemented that covers most cases, but often, you miss a few that can crash your app.

And having your app crash is never a great feeling as a founder when you then need to reach out to your users to explain why your service stopped working. You might feel dumb because that bug was easy to guess, or it should never have happened in the first place, but you forgot one little thing and it came tumbling down.

But instead of feeling down, ashamed or wanting to stop your project, you should consider this an opportunity. An opportunity to improve your service.

Granted, this bug wasn't great, but now, you're sure it won't happen again because you've implemented the needed precautions you initially forgot about. To put this differently:

Your product got better!

So next time you check your emails and see all the warnings about your server not working, consider this as an opportunity to improve what you offer. The issue you are having is the last time you'll have it, and everything will be better from now on.

Thinking to migrate to Firebase, I started to dig more under the hood of how Firebase was working. I liked the idea to have data retrieved very fast but was curious how it could send a lot of data under 200ms.

Turns out it doesn't. What it does is keeping a connection alive and receiving what the queue has to offer to that current connection. If data comes between two requests, it is queued and sent once the new request is ready.

I tried to implement something similar, and the result was crazy. I could send a "retrieve" request (GET in a RESTful way) that would respond immediately with an ACCEPTED status code, and once the requested data was ready, it would be published on that long-polling request or pending until that request would be open.

Of course, I had to rewrite quite some code, but it reduced the code I had implemented and made me write something that was clearer. Win-win !

After a few days of working on it, I discovered something problematic. You are limited on how many long-polling XHR request you can have in a browser for a given domain. This means that any user wanting to open many tabs will quickly have issues.

That's when I started to dig more into websockets. I was already aware of this while I was researching long-polling, but I had the misconception that it was not as widely available as it is.

It turns out that websocket is ready and working very well on all browsers. Moreover, I'm using Sanic on the backend, which has a very good implementation of websockets. Migrating the long-polling request to websocket was very easy, and the result was impressive.

So, how does it work ?

It's quite simple in the end.

I always try to have my server-side structure following the REST pattern, the best I can. So I did the same, but adding a realtime layer on top of that.

Concretely, there is only one command that requires data ; It's GET. The other commonly used commands (PATCH, PUT, POST, DELETE) are actions that needs validation and acknowledgement, so you can't fire-and-forget these.

I've added a custom options on my GET functions that, when enabled, will respond immediately with an ACCEPTED status code, and then continue to work by executing the requested work (listing the users, for instance).

Instead of returning them to the client, the results, fetched one by one for faster processing, are sent to a queue along with a "request identifier".

On the consumer end of the queue, a websocket event is sent to the user with the request ID and the data available. Once all the data has been sent, a "done" event with the request ID is sent to indicate the client the data has been sent.

The functions handling these GET requests and sending the data to the queue is build in a hybrid way : It will send the resulting data one by one to the queue for the websocket, but only if a specific header is present to behave that way (simply, the request-id set by the browser, which will be able to match the responses received by the websocket). If that header is missing, the data is returned as a standard API response in JSON.

Any POST/PUT/PATCH/DELETE requests are synchronous and always respond once the request work has been done, with the updated information (or removed in case of a DELETE). But in parallel, an event is fired to all the websocket connections to notify of any changes.

That way, when a user updates some data, all the other connected users have their data updated in realtime.

Of course, a security layer is added and only the users belonging to the same organization have these updates. This means that an organization won't have access to data from another organization or be notified from their changes.

This solution is close to what Firebase is offering, except that the logic is done on the server side (filtering, ordering, etc) rather than on the client side. But that's just a decision to lower the amount of data the user will handle. Every data received while connected are stored in the memory of the browser and the code listens to any changes (update/delete) and updates them appropriately.

When the user closes the tab and re-open it later, the first connections loads the essential data again and will receive any subsequent changes and apply them.

This is done simply because it would be too complicated to track the database state right before the user closed the tab, and send only the list of changes when they come back. The data sent when re-opening the service is not that much and with current Internet bandwidth, it only takes a few ms to fully load. Moreover, the data loaded is done in the background while the application shows key elements, so when the user access these data, they are already present.

Conclusion

I hope this was interesting. The whole quest of finding an efficient, fast and always-up-to-date interface was quite challenging and made me rethink how we load and access data.

This required me to re-think and re-write how the backend behave, and how the frontend could rely on the browser to speed up the process.

A future iteration of this would be to rely even more on the browser features to store data (IndexedDB for instance) in order to fasten the rendering of the application, but reload everything from the server and update what is needed.

Taking into consideration slow browsers and slow internet connections will be something else to dig into, which gives this project a nice and complex technical thought.

It has a lot of features that any web developer would love, such as Authentication (with many protocols if needed, including emails for password loss, account validation, etc), Offline mode, a really fast query model, and real-time synchronized data across all the services.

The whole set resonates well with what we want at Fernand, which includes being fast (data should be loaded in milliseconds) and reliable (it should never fail).

Firebase solve a lot of these issues, and that's what pushed me to heavily consider it. With it, we won't have to worry about the database being down, slow queries, WebSocket failing, etc...

Moreover, the code required to implement is small and easy to get started, which is a great plus too.

But I'm afraid of the issues related to now having access to the database directly. I can work my way around the restrictions now (not building complex queries for instance). But if tomorrow we need to calculate the number of users based on some advanced criteria, we will have to download the database locally, and import it on another datastore (such as MongoDB) in order to run these processes. It feels cumbersome.

Another problem I'm not comfortable with is duplicate content. With a relational database, you can have the guarantee that one element won't be present twice in your database. With Firebase, there are no unique checks done, so you can have two incoming requests having the same data, and, somehow, end up with two "unique" values.

One other drawback is that I will have to rewrite the entire backend system we've implemented to now use the Firebase DB instead of MySQL. We are still small and starting, so it's not the end of the world, but what we have is working really well, and we will have to test it again with the new structure.

I agree that Firebase is incredibly fast to return data - my tests shows an average of 20ms! - But you can be the fastest in the universe, you won't be enough if your user is loading 5000 tickets with a slow 2G connection! You can't compete with that! Not even Firebase.

So here I am, pondering the pros and cons, and being quite stuck on the matter...

See you next episode for my takes on the subject!

Thanks for reading.

When I first developed the frontend part of Fernand, I went the naive way: The API would load each endpoint when needed, by respecting the RESTFul protocol.

That meant loading all the conversations when you'd hit the "/tickets/" page. That meant waiting for all the conversations and contact details to load.

Granted, I've spent a fair amount of time on improving that endpoint, but it still took about a second to render it properly.

But this wasn't the main issue. The main issue is that by doing so, the content (messages, responses, notes, and events) wasn't loaded, because we couldn't know in advance which one you'd open!

So once the loading was done for the listing, we would wait for the user to make a decision before loading what was needed.

When you would load a conversation thread, it would then fetch the API to load the messages, the contact in details (subscription status, latest payments, etc) and also the list of related conversations from that same user.

That loading could take some time - about two seconds - which would result in a bad User eXperience where you would have to wait when switching between tickets.

Not. Great.

That's why I decided to change the way we would load the data. The idea was that we would constantly load the data we expect the user to view before they make any actions. That way, once they click on a conversation, they have all the details needed in a few milliseconds.

The trick in all of that is to take into consideration the limits of what our users might have: We might reach a memory limit if we load too much, we could slow their bandwidth or worse, use all their data allowance!

Here's my discoveries.

First approach: Load the linked data in the same request

My first test was to consider loading all the data related to one conversations in the same request. This forced me to rewrite a bit of the API to return the batch of conversations requested, with extended informations in it (messages, events, notes, contact, related conversations and payments informations)

I implemented a straightforward approach on the API side and I'm pretty sure I could have improved the queries to the database, but I first wanted to see what would be the result.

Loading a batch of 25 conversations per request was taking, on average, 3960ms. Loading 1600 conversations I have on my local machine took about 4 minutes and 4 seconds:

Keep in mind that in order to be useful, there is no need for the user to load the entire 1600 articles! The first 25 batch is enough to get started, and the rest is here in case the user needs it. That means that once the first request is done, the user can start using the app.

... but still, having to wait 4 seconds to get started is too much for Fernand, so we need to improve that.

So here come the second approach.

Second approach: Loading per batch of types

The previous method had a major drawback: We had to wait on the request to finish to start the second one, because of the "cursor" pagination. We couldn't just ask for the n, n+1, n+2 and n+3 items.

Waiting on one long request is not perfect so instead, we rewrote the backend to load the data as flat: Every related instances (such as messages, contacts, etc) would then be loaded by the frontend if/when needed.

Here's how we did it:

When loading the conversation listing, a request asking for the first 25 tickets would be sent. The data would be returned with IDs instead of linked data. Then, the Frontend would push into a "batch" queue every ID needed to be loaded, per type (a queue of IDs for the Contacts, the Messages, the Related conversations, etc). That Batch system would then throw a new network request everytime the queue would have a size of 10 entries - or - when the loader would have finished.

Doing so has tremendous advantages :

• We would add on the Batch queue only the IDs we don't already have loaded or that aren't already on the queue. That means if we have multiple time the same ID (same Contact for instance), we would only load it once.
• By loading only once, we reduce the amount of database query
• We also reduce the size of the payload

So definitely a bigger win.

• The name is easy to remember

• The design of the landing page is nice

• Customer support is a trending market

All in all, I think the makers behind Helpspace have a chance to do something nice with their tool, and that's why I decided to do a case study about it.

I initially used GrooveHQ for quite some time. It was the best tool and worked nice, but they increased the price twice and ended up in a pricing strategy that wasn't for me ($19 per seat monthly, with a minimum of two seats ... For a sole founder, it doesn't make sense.)

I am currently using Front which provides a complete tool for a good price, but it has its few quirks. For instance, Twitter's integration comes at $20/month. It's too much when you are on the $9/month plan!!

Needless to say that I spent a fair amount of time comparing a lot of competitors, looking at their features, pricing, options, and differences.

So when I saw this newcomer, I was interested to know more about it, and the first impressions are positives.

An earlier version of this post was targetting the makers directly by saying "you", but it gave an arrogant tone to the document, and as such, has been rewritten. It wasn't my intention to give this feeling.

Feedback

There are currently two main ways to offer a landing page:

• A short version with links that point to specific pages (features, pricing, etc)

• Or a long version that contains everything. Bonus to point to also have a (not duplicated) dedicated page for each point for SEO and advanced explanations.

Helpspace's landing page is nice because the design is lightweight but as a potential user, I think I was expecting more. The main lacking point I found was the absence of the price directly accessible. Let me explain:

I started to scroll, eager to see the features, and they started to convince me (great!), so my next thought was "how much?". But from there, I couldn't find the pricing options: I had to go all up to find it on the menu.

I would recommend either have the pricing options on the landing page directly (where a quick scroll brings it into view) or have a sticky menu to always have access to the pricing page.

Bonus point if you set the pricing page next to the features, as it was my next thought.

Hero

Also called Above the fold. It's the most important element of any website because visitors that are hesitating will leave your website if the hero doesn't convince them.

The image is great because it shows the potentially interested visitors what they'll get if they create an account, and it looks like the makers have made an interesting work in analyzing their persona:

The simplification of the image is made in such a way that for someone that knows how customer support works, it's easy to target the messages, the comments, the user's info, etc. Nice job!

One point that bothers me though, is the headline. If you scroll a little bit, you'll get this:

Keep Your Support Under Control
With HelpSpace you will keep your incoming requests and questions in line and won't fail your customers!

This feels like a headline... too. There already is a headline in the hero section so I would recommend choosing between one of them. Both are great and this might depend on everyone, but what I highly recommend is to spend a lot of time working on the phrasing and the words used.

This utterly important because it's the first thing your visitor will read. They need to understand it without reading every word. If you don't catch their attention there, you might lose them even before they start scrolling!

Video explainer

Customer support tools can quickly become feature-rich and having just an image on the landing page might not convey all the great features the service has to offer.

What I would recommend instead, is to keep this image (love it!) but add a "play" icon in the middle that suggests a video. When the visitor will click on it, a modal would open with a 1-1:30 minutes video of what Helpspace has to offer.

More and more visitors now rely on video to have a quick understanding of what a service does, and offering this as the first step for your visitors (remember, it's the first thing they'll see), will play an important role in your conversion rate.

Features

One big issue of Helpspace is the competitive market. And other than fighting on the price, another possibility is to fight on the features, and how they are available. The features section of Helpspace works great because it's light but goes straight to the point.

The fact that it's not screenshots, but real interactive elements instead is a nice touch! But it can be a double-edged sword! Being used to have non-interactive elements, I thought they were animated gif and didn't bother to click on it.

The first feature is great because it shows you how Helpspace solves a frequent problem: How to handle multiple channels. The colored pills? Clever!

The second feature shows how neat the interface is when replying, and how the details (tag, date, etc) are displayed. This gives an insight into what to expect if you create an account.

Unfortunately, the interactive integration leaves me eager: I'd like to know what happens when I click on each item (tag, canned response, users?, three dots?) because clearly, I can (a "hover" effect is applied when you place your mouse over the icons), but when you click on it, nothing happens.

I'm pretty sure putting these elements here instead of the basic screenshot was a lot of work, but what I would recommend instead, is animated images (can be gif, or small videos), showing what can be done. The video format helps the visitors understand they won't be able to interact while showing them what can be done.

Since Helpspace is pretty recent, I'm sure that the dev team is hard in working on the set of features, and I would recommend them to put at least one more feature here once it's ready.

For information, here's what I would expect from a customer support service. Of course, depending on the vision of the founders, not everything will/might be implemented, but it can help :)

• Canned responses

• Snooze (mark a message to be re-opened later)

• Automations rules

• Team management (assigning tickets for instance)

• Search engine (with filters maybe, like GMail?)

As for animated sequences, here are a few suggestions:

• Receiving a new email

• (Quickly) replying to an email

• Replying using a canned response

• Adding a rule to automate the workflow

• Assign the ticket to someone on your team

• Change the status of an email (to a custom one maybe?)

• Search over all your messages

• Switch the view from open/archived/deleted

Pricing

As I've mentioned earlier, I would recommend having an "always accessible" way to view the pricing. It could be on a sticky menu that stays at the top or place the pricing directly on the page. The idea is to have visitors do the less work possible up to the account creation (and get that precious email).

By the way, on a side note, I would recommend to also have the pricing plan in the footer. It's not the case on Helpspace's website but it can only help ;)

On the pricing plan per se, here are a few suggestions I would do:

• I would offer two email channels instead of one. Why is that? Simply because with only one email channel, what is the difference between my inbox and Helpspace? By providing two, you start to differentiate.

• Limiting to 5 emails on the Pro plan at this price is good, but convey the idea that Helpspace is only made for small businesses. If the idea is to attract bigger customers, I recommend offering some kind of "Enterprise plan" with higher limits.

Pricing is hard. I recommend you to try - a lot - and don't hesitate to increase the prices too.

As for the enterprise plan, one possible way to make it work with bigger clients is to set a base price (say, $49 for 20 channels) and then mention a "+$2/m per channels after that".

Don't go in too many directions

Customer support is a wide area and can integrate many many extra features. Helpspace suggests they are working on two future features (at the time of the writing):

• Ticket tasks

• Knowledge base

These are very interesting features, and clearly, features that might be asked in the long run, but what I would recommend to the Helpspace team instead, is to first focus on the core features of a customer support service.

Things like canned responses, rules, team assignments, tags, are - in my opinion - more important to implement. Then, once each of the core features are implemented and works great, and only then, I would recommend starting to add satellite features.

If you follow the features of your competitor, you will be just like them. If you are just like them, you won't differentiate and you will be lost in the crowd.

Here's what I would do (but again, this is my point of view):

I would focus on the missing features that are essential when handling support (automated responses via rules, canned responses, office hours, etc) and put the ticket tasks and knowledge base items in the pending todo list.

With only the core features, I would be able to lower the price. Yes, this is tricky because everyone says "increase your price", but in Helpspace case, they are in a very competitive market and the price will be a big decision maker since they are new. Take a look at this diagram:

The idea behind this is to get a lot of new customers that are not looking for tons of features (... like knowledge base) but just want a nice interface to manage their support. Helpspace will fit perfectly right in. This will help you grow, get customer feedback, improve the service and add more core features or master the current one.

Once you will have reached a certain amount of customers and have implemented all the core features, you will then be able to work on the extensions, offering tickets, knowledge base and even more, and increase your price from there (or offer these as paid features).

Conclusion

Helpspace looks nice and I think the makers are on the great track of having a really cool SaaS product. I hope my thoughts were helpful and I wish them good luck!

I’ve been using and I knew about ImprovMX for many years and it was, for me, one of the tools that were always present. The issue was that the support was non- existent and if you had the misfortune of having a typo in your email, you could say goodbye to using ImprovMX (true story).

For this reason, I searched the owner of ImprovMX and offered to acquire it in the objective to improve and grow the service. Turns out he was open to discussion and we quickly found common ground. Thank you, Alex! :)

I was excited to acquire ImprovMX, provide great customer support and improve, iterate and make ImprovMX a best in class for email forwarding.

Once the transition was complete, I initially started changing completely how the emails were handled. It was initially using Postfix, but we decided to scratch this and build a customized suite in Python that allows us to do almost everything we wanted, including being able to know how many emails are in forwarding chain (how many we received, how many got accepted and how many got delivered).

We had to implement many systems to avoid spam abuse, greylisting and blacklisting, and we are getting better and better over time.

After that, we worked with Antoine on making a new website to show our commitment to providing a great service. We focus on what we do best: Making a simple, yet powerful service for everyone to use. You can get started quickly and forwarding emails just takes a few steps and can now be done in a few minutes.

Email, in general, is not a piece of cake. Along with all the intricacies of having to manage SPF, SRS, DKIM, DMARC, you also have to fight against spammers, getting blacklisted from time to time because some spams manage to get through your service, and tons of other vicious things that make email …. so awesome!

What excites me the most with ImprovMX is the reach. We are just getting started here and forwarding is just the beginning. We have so many projects in mind related to email that we need to define a clear roadmap for the future and be sure to play our cards well.

The way we structured our servers and how we wrote the code will allow us to extend and be able to, in the near future, provide many great features to help our customers, help developers and provide more than just email forwarding.

We are just getting started, and we are eager!

While making this decision, we had a long (and unfinished) talk about how we could monetize Transferslot in such a way that is a win-win for everyone.

Many ideas came up, and I think it’s interesting to share them here. It might help other owners of different marketplaces along with giving you an idea of what we thought of each possibility.

The obvious one: Listing fee

Of course, we could do like the main one does; asking for a payment when submitting a project.

Having been on the seller side of Flippa, I know that I didn’t mind much about paying for listing my project. I had a fair idea of how much it would cost, how much I would gain from it so I was able to make a rational decision on how which option to choose.

The issue is that it’s 1) not the case for everyone, 2) doesn’t guarantee you a successful sale.

The point 2 is, for me, the most important one here! We don’t think that it’s fair as a marketplace provider to ask for payment for something that might not work. We want our seller to be happy if they pay us, not crossing fingers and hope for the best.

Paying for options

One of the things we offer right now, and one that I like quite the most, is offering the listing for free but offering options that aren’t free.

Two things we currently offer are the option to be private, and being on a dedicated newsletter.

The dedicated newsletter is really interesting because it clearly shows the interest for the seller (increased visibility) and can easily justify the cost (currently at 50$).

That’s one strategy that Flippa implements too (even though their price for having a dedicated newsletter are way higher, but they also have way more subscribers!).

Limiting the number of buyer’s requests.

One other option we discussed, and almost implemented, was to allow for three buyer’s requests to be sent to the seller, then block the future messages.

If the seller wanted to read them, he would have to pay us to “unlock” the pending messages.

At first, it looks like the listing fee option; There is still no way that the sale will be successful, and it’s true. The reason why we still thought it would be a good idea was that with the listing fee, you don’t have a clue about the potential of your sale. With this solution, if you have more than 3 requests, it means you got some interests, and thus a higher chance to sell.

One con about it is that if the seller doesn’t decide to pay, the potential pending buyers won’t receive a response and will think that either the seller or Transferslot, ignore their messages. This is not great. (Of course, we could handle the pending message after a certain time, but it requires more work that aren’t really necessary in that case).

Three alternatives are possible in this possibility, such as :

• Allowing for 3 free messages before blocking the next ones
• Hiding name and email from the beginning. The seller would have to pay to get the detailed information (same issue as the listing fee)
• Block from scratch (same issue as the listing fee)

Relying on trust

This is one of my favorites, even though it has a high chance of not working.

The idea is simple: We would ask our sellers to let us know once their project is sold (they are kind of required if they want the project to be removed/updated on Transferslot). Once we acknowledge that the sale was successful thanks to Transferslot, we can request the seller to pay us a fee (15% for instance) of the sold price.

The issue here is that:

1. We can’t enforce a seller to pay us
2. They can lie, saying they sold outside of Transferslot.

That’s the reason I named this part “relying on trust”. Maybe not all the sellers will pay, but if a few do, it will still be beneficial.

Being legal

Improving the “Relying on trust” part, we could require our sellers to sign a document which engages themselves on having to pay a fee if we successfully help them make a sale. Having to sign this document will enforce the seriousness of it and will decrease the risk of user avoiding to pay the fee.

Being the middleman

Another solution would be that instead of buyers reaching out directly to sellers on Transferslot, it would be us that receives the messages. We would either reply directly if we already know the answer or reach out to the seller for more details.

Of course, buyers could contact the seller directly from their website since the data aren’t hidden, but we would rely on the fact that it’s easier for the buyer to just fill the form on Transferslot’s website instead of having to search for contacts credentials.

One of the cons here is that it will require a lot more work on our side, with a low response time. But on the pros, working as a middleman will give us the chance to better handle the sales, eventually catch bad sellers faster, and requesting a fee upon successful sale.

Being an escrow service

Finally, one of the most advanced way we can earn money while sharing a win-win with our customers.

By implementing two of the discussed options here; Being legal and being the middleman, we will ensure that the transaction occurs and it will help us identify any issues, work with both the seller and the buyer.

This will also provide a chain of trust as we will manage the whole transaction and ensure everything goes smoothly. Along the transaction, taking a fee will be easy and evident.

But there are big disadvantages to doing so. The first one is the time involved. We won’t handle one project at a time, but multiple. Managing the discussions between the sellers and buyers, hoping we don’t mix the projects and provide incorrect numbers.

Moreover, by being in the middle at this level, we engage ourself legally too. If the sale goes south and one member has already invested in it (paid the price or send all their code for instance), all the issues might fall on us. At this level, I’m not talking about small angry emails, but a potential lawsuit!

Even though that’s clearly the best option there, it’s also the riskier. That’s why we haven’t done it yet.

Conclusion

We still don’t know our next move regarding Transferslot. The difficulty here is that we are in the middle, between Flippa and FEInternational, and we can’t implement all the options.

I think we need to find what service we want to provide from A-Z and use a revenue model that fits greatly with the service. There are a lot of options here, some more honest than others, and that a key point — at least for me — honesty.

Thanks for reading, I hope it was helpful for you. If you have any other ideas we could implement, I’d be happy to discuss them with you. It’s also not impossible that we try some of the mentioned methods in the future on Transferslot, and see which one works best.