First They Steal, and When You Win, They Kill You: An Indie Developer vs. Government Tech Monopoly

Legend

• EMP — a unified mobile platform providing API access to city services (utilities, fines, education)
• MRKO — the old electronic school diary system
• OEZHD — the new electronic school diary system
• My application — an app I developed 1.5 years ago (3.5 years if counting older versions)
• Me — a former schoolboy, recently graduated from a typical school, now entering university

You can skip the full story and jump straight to the "WHAT? HOW IS THIS POSSIBLE?" section if you prefer.

What I'm Fighting For

Children can study well and even excellently — motivation matters. In reality, circumstances prove bleak. Children often feel forgotten by their parents; teachers rarely inspire a love of learning.

The worst part: nobody tells children they're capable of academic success. They simply don't know it's possible.

Most lessons involve monotonous information delivery. If your school has even one engaging teacher, consider yourself extremely fortunate — your child might actually learn something.

What I Propose

I created an assistant. Every child could have someone always nearby — someone ready to guide them. The assistant subtly demonstrates that learning is achievable without excessive effort, while alerting students immediately to problems.

How This Usually Works

Typically, we address situations after students have dug themselves into deep holes — holes that are nearly impossible to escape. Near the end of the semester, parents open the diary asking, "What's your final grade?" Children respond negatively. Together they attempt to earn 20 grades in one week, inevitably failing. Children internalize the belief that academic success is impossible.

This explains the popularity of exam tutoring — students attempt to learn everything they skipped in the final year.

"People address educational problems only at the end, when solving them becomes impossible."

Mathematical explanation: The final grade rounds the average grade. The average grade equals a weighted arithmetic mean. The more grades students receive, the harder it becomes to change the average value.

How to Solve This

Stay involved from the beginning — not when it's too late.

The application includes core functionality:

1. Advice — the app calculates how many top marks are needed to reach goals
2. Hints — color-coded subjects. Green indicates the goal has been achieved, yellow indicates uncertain grades, red indicates preparation is needed
3. Push notifications — students cannot "sleep through" grade updates

Official diary on the left, mine on the right

User interaction typically follows this pattern at the start of the year, when few grades have accumulated yet:

1. Student opens the diary
2. Main screen shows advice: "Hey, you'll have an A in biology — just get two more A's!"
3. Student remembers this
4. Student opens the diary tomorrow, sees seven lessons with homework. Only biology is "red," so they start studying that specifically to earn the A
5. Something from the completed work sticks. Understanding of the subject increases
6. When the student receives grades, a push notification prompts them to check. Good grades earn a green-colored congratulation and the realization that studying well is achievable. Bad grades alert students immediately so they can fix them

Students develop a constant experience of success. Problems are resolved from the start. They internalize that results depend on them.

I Call This Fighting

The API wasn't designed for quality applications.

I spent half a year requesting support for a simple update — to stop rounding average grades. They did nothing, merely delaying until they could provide a new API.

The request came in December; the new API arrived in late April. One month before the school year's end.

What's This New API?

The Department of Information Technology (DIT) began developing the new electronic diary system (OEZHD). I noticed their users couldn't access my application because their login didn't work.

Then something unexpected happened — my competitors' authorization succeeded.

After emailing support, I learned they had received "testing" access while I couldn't get it. They also bypassed the standard platform authorization completely — not even requesting passwords. When I asked why, the response was: "We shouldn't reveal your competitor's authorization logic." An especially impossible position when the data comes directly from DIT servers.

WHAT? HOW IS THIS POSSIBLE?

My competitors' diary apps required payment for diary access and charged separately for grade analysis. They had stolen my idea and were selling it.

Altarix Company created the government services platform and EMP. The official "Government Services" app is the official diary application.

Now let's expose the connections between altarix.ru and the competitors:

1. The website cloud4smartcity.com sits on the identical IP address as altarix.ru
2. This site sells Active Citizen, government services, and the KidRadar product
3. KidRadar represents Taktik Labs' products — the creators of the competing diary app
4. Bonus: devs.hostoasis.net hosted all the website templates

UPDATE!!! The site was cleaned, but the internet remembers everything.

These companies are tightly connected.

Their app's goal: profit from the inadequacy of the official competitor they themselves didn't properly develop. They created the Government Services app but omitted keywords like "MRKO" or "Electronic Diary" — so nobody could discover it.

Without my competition, anyone googling the school diary would find only their paid application.

They completed the government contract and earned payment, then profited again from a paid app. Convenient!

Diagram showing the connections

Cat and Mouse

Searching for the school diary in the AppStore showed my application first, the competitors' second. The platform employees constantly sought reasons to block me.

Late 2016. I was still parsing the website; my audience had reached 100,000 users. The competitors couldn't reach first place despite trying — they even advertised on social media, specifically targeting my user group.

At one point, 300 users saw crude 18+ advertisement content, apparently due to an improperly configured Google AdMob filter. I fixed it that evening, but not before they changed and broke the parsing multiple times daily.

I understood they were trying to "eliminate" me. Switching to the API seemed safer — they couldn't block that.

I was mistaken. Once I started using the API, I received:

Email blocking API access

Note the sender.

They found some excuse to block my API access. I thought: "Okay," and offered to delete excess users. They ignored this and blocked me immediately instead of "in 14 days" as stated.

Imagine the convenience? You control the platform, ban me, and my entire audience migrates to you!

After the blocking, I attended meaningless negotiations at the Department of Information Technology — these were actually just stalling tactics. (Stalling until I fell to second place.)

Examples included:

1. Meetings scheduled just hours before
2. They demanded reports guaranteeing no future mistakes. After I provided one the same day, they found different reasons
3. "Send us your source code"
4. "Build API-compatible apps but we won't provide documentation"
5. "Apps with bugs will lose API access"
6. "Meetings rescheduled repeatedly for weeks"

The situation peaked when I sat at the DIT offices with an application supposedly working — developed from strange documentation without test API access.

We sat in a room: me and two employees (one from DIT, one from the platform). One said: "Ready? We're enabling access now; if anything breaks, we close it," with clear mockery visible. I knew there was no turning back (though it wasn't necessary either), so I responded: "Yes."

Access was opened and everything worked perfectly. The first launch displayed all data correctly. Their faces showed confusion — I knew access would be opened and I would release the app.

They exchanged glances with this dialogue:

— So, enable access?
— Yeah, since there are no errors
— Sure?
— Yeah
— Hmm... Okay, we're closing access now; we'll open it tomorrow.

They left. Tomorrow came — no access. It only eventually opened. However long they stalled, my application remained first in search. After this, constant blocking threats followed, which I continuously countered.

Summary

Throughout this entire period, they couldn't defeat me. I remained in first place.

They blocked my application without considering the children — who were now left without a place to check their homework.

They deliberately avoided creating free alternatives because they wanted profit.

Early summer 2017, I asked the platform: "Will methods or functionality change?" They answered that they didn't know yet.

August 1st, I received a notification: the API ceases to exist. They requested that I inform my users to use the government services app instead.

Who motivates the children now?

Official Response from the Department of Information Technology

(Forwarded by a Habr employee)

Artyom Ermolaev: "Starting September 1, 2017, third-party developers lose access to the Electronic Diary API"

Recently, public information appeared claiming that DIT is closing the Electronic Diary API for third parties. We want to clarify — we deliberately and consciously closed access entirely.

This decision addresses ethical norm violations by third-party diary app developers, as well as our plans to substantially raise the level of student information security. Previously discovered API security vulnerabilities prompted transitioning diaries to a unified authorization system on the city's official website.

The changes mean: first, only fully authorized users who have correctly provided their phone and email and uniquely identified themselves can access the diaries; second, we will use identical protection levels as government services.

Some believe diary grades and homework aren't confidential. Few consider that diaries also contain child and parent contact information and serve as additional content platforms for children. Carelessness or inexperience from certain developers — their inability to analyze consequences — caused one massively popular unofficial diary app to host pornographic materials mid-school year. This created serious parent backlash. DIT received numerous complaints, some legal. This incident nearly destroyed the Electronic Diary — public criticism devastated us. Yet the respected developer called this situation merely: "probably I messed up Google AdMob filtering." He treats this case as a simple error, despite thousands of children viewing inappropriate content. Who guarantees such "mistakes" won't repeat?

DIT guarantees this exclusively through official diary applications. Therefore, closing unofficial resource access followed naturally.

Simultaneously, we recognize that popular apps succeeded in providing desired services with functional advantages versus official diaries. We would adopt positive experiences, discuss possible third-party collaboration formats, and ensure that efforts creating convenient products weren't wasted. Therefore, I publicly invite Levan to discuss further work details.

Author's Response to DIT

1. Your initial email stated the API shutdown occurred due to the OEZHD transition; now you claim advertising caused it. Where's the truth? Following that incident, you restored API access despite extensive stalling — no problems occurred subsequently. Why remove it now? Provide the real reasons. Share them.
2. Why didn't you address the Altarix connection?
3. You mention: "Previously discovered security vulnerabilities." What's worse: an advertisement that 300 people saw, or security vulnerabilities? Therefore I ask: "Who guarantees such 'mistakes' won't repeat?" Or do errors happen universally?