My journey and challenges developing a tool while relearning to code

Hi there!

I'm Cali from Brazil.

Inspired by some concepts, I started developing a simple tool to help get an optimized execution sequence for a project or cycle of a product.

For now, it is in a subdomain on vercel: https://scopefully.vercel.app/

To start, the first step there is to map the scopes of a project. Then classify the items (risky, nice-to-have, automatable), set dependencies among scopes, and finally get the sequence.

The intention is to minimize many obstacles being discovered only later. Delaying the entire project or not being able to complete it in the desired period.

The generated sequence takes some care to optimize execution:

• it considers dependencies between scopes and classifications of scopes and tasks.
• scopes with risky items - unknowns, or tasks that are not part of the usual work - are the first ones in the sequence to allow dealing with the risks as soon as possible. It's intentional to avoid. If it depends on a scope that is not risky, that scope appears before the risky one with the hint to do as little as possible. If possible, simulating what would be necessary, just to unlock the risky scope. It can be important to note, otherwise, the person could forget that the focus at the moment is to unblock and develop the risky scopes. And the risk-free scope will come later again in the sequence to be executed normally.
• risky tasks can have mitigating actions. These actions appear before any task in the sequence. Mitigators can be things like research, spike, POC, etc. The intention is that the person only starts executing a sequence, after having mitigated the main risks.
• indispensable scopes are prioritized ahead of nice-to-have scopes. Indispensable tasks are prioritized ahead of nice-to-have tasks. Those are all broken down into steps in the sequence.

---

Scopefully and my journey

The tool itself is at such an early stage that I don't even know if it would be appropriate to share it here.

But I decided to share a little of my journey because maybe it could be interesting for some people regardless of the tool itself.

Many Indie Hackers have already inspired me by sharing their journeys. I am grateful to each of you.

Please feel free to share your perceptions of both the tool and my journey.

---

My main inspiration for this tool was:

• Ryan Singer's texts on digital product development - about scopes and sequence - and Shape Up (Basecamp).
• DiSSS (Deconstruction, Selection, Sequencing and Stakes) : a framework created by Tim Ferris, devised to help people master new information-based topics
• DUST (Difficult, Unclear, Scary and Tedious) : a method created by Graham Allcott that identifies why you are procrastinating.
• Procrastinate on Purpose by Rory Vaden

---

My challenges:

1. I'm relearning how to code while I'm learning Svelte and SvelteKit, after many years without developing software, since 2011.

It has been mixed days of excitement, frustration, study, and trial and error. Challenges and frustration not only because of learning a new framework but because of many concepts, processes, and tools that I already lacked practice or I didn't have experience with (git, vercel, vs code, reactivity, etc).

In the middle of the way, I decided to read some excerpts from the book "Grokking Simplicity" and refactored many parts of the code. It was for learning and fun. But it took me several hours of work.

Although I started to want to validate the tool with some audiences, I wanted to take the opportunity to learn more about the framework and refine functional language patterns.

2. Value proposition

I chose a problem that I see in product teams. The lack of a process and the combination of an organization's culture of urgency, lead to it.

But, although this seems like a problem that can partly be solved, I'm struggling with how to present the value proposition.

3. Many people in the product world are terrified of the word 'project'.

And maybe they are the main audience. So I have to find a way to speak without causing a scare. I thought of 'product cycle', which would also include sprints (for those in the scrum world).

4. Promotion & Feedback

I have no experience building in public and my audience is minimal on Twitter (<90). I tried to share some evolution of the tool, but normally, I have no interactions in what I post.

Probably I'd need to grow a lot of the audience and participate more actively in the threads of other people, especially those related to the niche.

My network of people in the digital product universe where I have the greatest influence are Brazilians, but I don't have connections with them on Twitter.
Two years ago, I had the most influence on LinkedIn. I published texts regularly and promoted events I talked at. However, I use social media less now, and LinkedIn has limited how many people see my posts, even though I have 4,500+ followers.

So this makes it difficult to get feedback and encourage others to try it.

---

No-code - Why did I not try to use no-code tools to build Scopefully?

I've been playing with no-code for a few years now. I have an annotated list of over 500 tools. My wife jokes that I'm a 'tool sommelier'.

I've used several of them more thoroughly (Bubble*, Airtable, Zapier, Integromat/Make, Notion, Fibery, Coda), others I've played for less hours than the previous ones (bildr, budibase, weweb, uibakery, appgyver, webflow, softr.io, xano , subase, backendless, appsmith, etc).

For product development, I find several of the no-code tools very useful to me. Especially those in these categories:
a. automation/integration (zapier, integromat, etc)
b. auth/data manipulation/API (supabase, appwrite, directus, xano, etc)
c. building internal tools (appsmith, budibase, etc)
d. organization of information and processes & group work (fibery and others)

But in other categories, using tools to deal with frontend/backend at various times when wanting to do things a little more advanced, challenges appeared:

1. the plan that allows for such a thing seemed to me to be very expensive, especially when comparing the dollar with the Brazilian currency. I would be stuck on a monthly plan even for products in validation, spending on something that I consider expensive.
2. the tool did not allow to do something more advanced. Or, I could to code something, but the libraries were limited. Or, the data within the tool would be getting confusing and complex

In addition to "vendor lock-in".

Still, I don't rule out the use of some of them at some point and I continue to encourage more people and companies to try them.

There is a huge advantage that business people and designers can create products, without having to learn code, deploy, use git, or mess with other tools and processes. And these tools keep evolving.

But, because of the challenges mentioned above, I was trying to learn to code again when I wanted to execute new ideas.

Before diving into learning Svelte:

• I flirted with Wappler (https://wappler.io/). I watched some videos, and played around a bit, but didn't develop anything on it. Despite the fact that I would own my code, the monthly price seemed high, considering the Brazilian currency. And the learning curve would be high to learn a proprietary tool.
• I tried anvil.works. Despite using code, there's a lot of simplified stuff in there already (database, authentication, etc). It allows doing everything, even the frontend, in python. And you can integrate with javascript libraries. I loved the proposal. But since I should understand more about code again, I decided to go one step further, and get out of the possible limitations of the tool.
• I played around with Bildr and weweb.
• I researched some javascript frameworks, focusing on frontend/backend, simplicity, and enjoyment.

After some experiments, I chose Svelte with SvelteKit.

So, I took a concept that I already wanted to try to develop, to help me with the learning.

At least for the frontend and backend code, but probably I'll use some no-code tools from the categories I listed above.

Svelte and SvelteKit are easy to code with and give you the freedom to integrate with any other no-code tools. It's free and open-source.

---

Pause for sharing my experience with Bubble. It's possible that some of you - no-coders - might ask why I didn't try to do it with Bubble. Well, it disappointed me a long time ago. I list some reasons in the text comment.

It doesn't mean the product is bad. In fact, it looks great to many people.
It just meant that it wasn't so good for me after a few tries.

The proposal to develop a complete product without code is incredible. And I believe Bubble was one of the first tools aimed at small creators with the ease of developing the entire product visually.

Kudos to the whole team! My interest in no-code/low-code started especially with Bubble and the articles the team published years ago. Thanks.

---

Product Discovery

Developing this tool is been more about learning so many things and enjoying the journey, than discovering a product itself.

I work supporting teams on product discovery and experimentation and have articles published on these topics, but this story of mine is not a case of product discovery, as I commented above.

But even if it's intentional. There was enormous danger in this.

I had to remind myself a few times why I wanted to learn to code again, learn a new framework, what subjects would be useful to explore and what skill level I would need.

What could I expect to learn on-demand, and what would make sense for me to already learn and practice to facilitate possible other experiments.

I don't say that I got all the decisions right.

Now I need to make decisions about the next steps. If I want to advance in the development of this tool, I would need to minimize the risks.

Critical questions are open:

• Who are the early adopters? Despite knowing an audience that could benefit, I still need to confirm several other questions.
• Do they understand this as a problem to be solved?
• Do they want a solution to solve their problem?
• Would they invest their time or money in this kind of tool?
• What is the best process   to meet the needs, before committing too much?
• How satisfied are people with that result before automating more stuff and developing more features?

Helping organizations and teams with product management is very different from doing it all yourself. Copywriting, research, design, coding, deploying, validation, promoting, etc.

That's why we need to know what not to do, where to focus, where to use no-code tools, and how to build in public to get other perspectives and real audience feedback on an ongoing basis.

In teams, there are people for the most diverse roles.

Doing something alone, there is a lot to decide and get hands-on. Even when it's not our best skill and we don't have too much time.