Advices To Know If You Should Accept or Not a New Django Project

After 14 years doing web projects and mobile for clients in different industries - many at Django, others not - I look back and can realize that I would not undertake ever again at least 20 % of the clients with realized projects : I say 20% in my company;)

The clients have been bad experiences, but my company and I have had bad experiences as well. People who work in web and mobile development will be able to understand me. Often when you want to sell, give more work to your team, it makes us accept some projects that from the beginning are doomed to fail.

Thankfully, this does not always happen and for that we are still alive and we keep growing :) It is also true that nobody forces you to accept that project.

In this context, I going to tell you some tips that you need to remember when you want to decline the entry into a development project. I’m going to personalise with Django.

Approximate budget: In many cases, clients come to us asking for a budget and an analysis that they do not have clear, also it is complicated when they have to give you a budget. “That is the reason that I’m writing you, you have to give me the budget”.

After 2 weeks of work and dedication of the team, where you have written the requirements, the budget is not enough. We have found differences of 10 orders of magnitude. To make a sound proposal, it is necessary to have many, clear information requirements or to have an available budget (any executive or manager knows how they can spend)

Please, dear client, I need one of these options to give you a good service:

  • Clear technical and functional requirements and we will take care of giving you good equipment, planning and a right price (with the risks that we want to assume)
  • If not, with an estimated investment or expense budget on the basis of requirements, we can offer you a realistic solution.

Analysis or design is a work which exceeds the scope of the proposal and we think that it is necessary to invoice for it. In addition, this it is essential to do when the client is involved in order to have value.

Django is not enough

If you are really good at Django, in this real world that is not enough, you need compliance with the digital objectives, so it is necessary to have other profiles to carry out an in-house development project with success.

In fact, if your Django Back-end team is good, with clear user stories and UX/UI validated, the Back-end in Django is fast and effective. But you need more:

  • Strategy/analytics: It is important that the equipment which carries out the digital objectives setting is in every single part of the project also, and establishes clear KPIs that the client could measure.

  • Product Owner: It’s the person responsible for the product, the objectives and the coherence.

  • UX/UI: It’s a essential element in the project; conversion goals, understanding of the target, mobile adaptation etc. They have to be always in touch with back and front-end equipment.

  • SEO: It is a basic pack, if your strategy is acquisition, you need a SEO during the life cycle, generating plans and guides but always considering the stakeholder of the project.

  • QA: We are obsessed with this, if the client pays or not, our Django Agile QA methodology is our differential factor.

We can speak about more profiles for concrete cases, but I think that these are indispensable in a digital project together with back and front-end Django experts, where we have an excellent team but can not deal with everything.

There are many positions of the client in which it is necessary to begin to evangelize, and if it is not possible, probably it is better to leave it...

“I don’t pay for management, I want developers”: I wouldn’t call it management, I would call it concern about digital objectives of the project. If this role cannot be handled by the client (this is rare), during the project we assume this role.

“A QA, for what, do you have to deliver the project well-done?": Here we usually evangelize too, because we have a lot of tools and knowledge, about automation tools. It is important that the client is aware from the beginning that bugs will exist, but the goal is that they will be at a  minimum.

“I don’t want UX, I send you the design and I already have the prototypes in my notebook”: We don’t speak the same language, it is necessary that the UX role can be understood.

“I don’t care about SEO”: They are wrong, we care about SEO because it is our project, which requires some actions for a great job to be done at Google.

This could be optimal for other companies and projects. The experience tells us that this is not the right way. Is it really worth it? As I told you before, we sometimes have accepted projects in this way - business is business - but sometimes we have regretted it.

Do not go into maintenance or optimization of others if you are not sure.

It is too complicated to go into a client and carry out their digital ecosystem from scratch. At many times you need to develop a new Django site, but to maintain another at the same time. Be careful with this, because sometimes the relationship gets damaged during the projects.

A failure that we used to make was to say “The Django site that they have is shit, we have to remake everything”. Our experience tells us that the client is tired of this. We are going to give from the beginning real information, a real studio with good and bad news and so that, however complicated or not, is the way to solve problems.

  • Does it follow the standards and good practices in Django development?

  • Is the architecture right? Environment policy?

  • Difficulty with security updates or upgrade modules? it is core modified?

  • Status of documentation?

  • Code quality?

With this, you can generate a report of quality audit and not of sensations. This will serve to bring positions closer. If the client doesn’t understand that he must pay for that, then it could be a signal. If the client pays, the expectations with the maintenance will be closer. You have to take into account that if you need to remake the portal web due to an update, it's better you know it in advance :)

The support and maintenance is not guaranteed

It is completely understandable that the software fault of your project is resolved without cost during certain time: 6 months, 1 year. This is something that you have to close prior to contract and I think that is good for both sides. In Bedjango, we try to ensure that it is minimal, but bugs always appear. Another more important topic is the maintenance service and support, then they don’t only pay for the activity, whether for a failure software, consultation or monitoring of something, they pay for availability, response time, and infrastructure environment.

It is important to ensure an available technician, although in 8x5 to solve something, it is something that costs effort and money to the supplier and therefore it is logical that they try to recover from it. On many occasions we meet gestures of surprise. Maintenance is key for the long-term relations not only on the technical part, but to optimize the digital product and to obtain and to improve goals.

It’s true that there is a cost and therefore it’s good to be transparent with maintenance models from the beginning of the development project. Our vision is that a digital product needs a proactive maintenance service with results-oriented, flexible, available and efficient and then different forms that you have to collect. This model is not comparable to a good guarantee service so the expectation can’t be the same.

On paper, my vision is that if you work with digital projects, you need clients that can understand digital and they can’t do it, it’s important that they let you as a company, from offer phase and estimation onwards. It’s necessary to enter into a project regarding the relation, service and product as closely as possible and it will be a guarantee of success. This will allow you grow as a company and to then generate long-term value, stable relations and cases of success.


About the author

Let’s have a coffee and talk about your project


Let’s have a coffee and talk about your project


We use cookies to ensure you get the best experience on our website. More info.